1. Towards a Taxonomy of Security for Distributed Computing
Developing a General Taxonomy of Security Problems for Future Work
Timothy Brick and Jarett DeAngelis
University of Notre Dame
Department of Computer Science and Engineering
We want to talk about security from a distributed systems standpoint.
This has been discussed plenty of times before, but we want to introduce a framework for auditing and developing.
Distributed security is challenging for a variety of reasons, we are trying to categorize those reasons in such a way as to make the problem easier to tackle.

2. How Do You Know If Your Distributed System Is Secure?
Problem?
How Do You Know If Your Distributed System Is Secure?
(You don't, but we try.)
Our goal is to try to find a structure for doing this in an organized way.

3. To develop a taxonomy of distributed security issues
Solution
Aims:
To develop a taxonomy of distributed security issues
To test the taxonomy by analysis of the CC Tools
Taxonomy is useful for keeping the process of working with distributed security organized.
CCTools are distributed data software developed by the University for research applications which we will discuss later.

4. Final iteration of taxonomy
Three major areas, several sub-areas.
Can't discuss in detail—time limit
We'll go into these in more detail later.

5. The Chirp Distributed File System
Chirp: Designed to support distributed applications, focus on research apps
Creates a userspace abstraction over existing filesystem
Permissions system allows authentication via Globus certificates, Kerberos, UNIX auth, hostnames
Chirp chosen for a couple reasons:
It's here and in production, and NO ONE HAS AUDITED IT YET.
Fits the paradigm of “distributed system” well.
Runs own filesystem in a “bubble” over existing filesystem, - own abstraction, cross-platform.
Permissions system enables the “v” (reserve) right – user can specify sets of rights created in new directories. Will discuss this later

6. Programming-Related Buffer Overflows Race Conditions
Easy to detect statically
Detection tools have a lot of false positives (~400)
Race Conditions
Difficult to pin down
NP-Complete to find statically
Dynamically detect stat() - open() syscall pairs
Doesn't work on user-level file systems!
Exploit-finding tools don't always work – false positives and some things just go unfound. Remember: Race conditions exploit the pause between operations. That's it.
Detecting race conditions exhaustively (off-line) is NP-Hard.
We know for a fact that there is use of unbounded buffers in chirp_server from flawfinder, but none of them appear to be exploitable. Client has an unbounded buffer in its use of readline, doesn't do much.

7. Demonstration
Discovered an exploit of alteration of absolute namespace in Chirp filesystem.
Dynamic race condition detection tool finds user-level ACL check - open pairs.
(Based on rules given in Tsyrklevich & Yee 2003)
Race condition finder based on previous work by Tsyrklevich & Yee in 2003 – looks for “illegal” syscall combinations.
Do the demo here.
chirp_server won't run as root.

8. Especially if they don't know they're doing it.
User Wrangling
Users behave badly.
Especially if they don't know they're doing it.
How to prevent users from unwittingly compromising security? They: Don't know security
Don't read documentation
Engage in inadvisable behavior
Notification: Does the application tell the user what they're doing is bad?
Sensible Defaults (Default Deny)
Luxury of Ignorance: Term taken from ESR's essay. Bear in mind user doesn't know.
Administrative Robustness: Can't be sure an admin is available or that a user will go to them.

9. Trust What schemes do you trust? Reliability Appropriateness
Who does that mean you're trusting?
TIM
Reliability: Is it tough to break?
Appropriateness: Does it make sense for the application?
(Sanity check: cost-benefit/what do you get if you crack it?)
Trust chains: Who are you actually trusting?
Example: Hostname auth in chirp.

10. Evaluation Completeness Usefulness Adds to existing work
Still not entirely complete
Usefulness
Example: Chirp
Buffer overflow found in chirp client
Relative namespace exploit in server
ACL klobbering exploit in server
Some user interaction problems
Potential for abuse of trust systems
Adds to existing work in several ways.
Work still to be done to test completeness, and we'll never really have it complete.
Hard to quantify.
But it's better than we had, and people can add to it later.
Plus, it worked. Which is good.

11. CCTools available at http://www.cctools.org/
Conclusion
Useful practical results from analysis of Chirp
Useful taxonomy structure suitable for the future analysis of distributed systems
Try it!
CCTools available at
Well, we built it.
And it works. Or seems to.
If people add to it, then it'll get better and better.
And that would be good.