p. 1/26 The Asbestos Operating System Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey, Martijn Stevenson, Nickolai Zeldovich, David Ziegler, Eddie Kohler, David Mazières, Frans Kaashoek, Robert Morris MIT, Stanford, UCLA
p. 2/26 Target application Public servers Thousands to millions of users Store & handle sensitive data Security failures catastrophic - Divulge social security numbers - Divulge recommendation letters - Divulge credit card numbers
p. 3/26 The worst of the worst: Web services Web services are notoriously poor quality code Much less audited than typical code - Programs are site-specific, often highly proprietary Often coded under duress or high-pressure situations - E.g., had to cope with sudden load spike - E.g., forced by some professor to special-case email address Often delegated to junior programmers - Easy to make stuff that works for honest users
p. 4/26 What goes wrong? Buffer overruns Trojaned machines SQL injection attacks (quoting errors) - Most CGI programs have column level access to databases Application logic errors Social Engineering Find a UPS box full of hard drives Lost laptop with 100K Berkeley applicant SSNs
p. 4/26 What goes wrong? Buffer overruns Trojaned machines SQL injection attacks (quoting errors) - Most CGI programs have column level access to databases Application logic errors Social Engineering Find a UPS box full of hard drives Lost laptop with 100K Berkeley applicant SSNs We will attempt to address first four problems
The problem p. 5/26
The problem p. 5/26
The problem p. 5/26
The problem p. 5/26
p. 6/26 The Goal: User Isolation Bob should not have access to Alice s data... Even if there are bugs in the application
Desired Behaviour p. 7/26
Desired Behaviour p. 7/26
Desired Behaviour p. 7/26
p. 8/26 Approach Use labels to track information flow - Long used by OSes to enforce mandatory access control Not previously applied to e-commerce New application raises some challenges - Scalability - Label accumulation - Integration with HTTP But if we can solve these...
Controling information flow Message-passing operating system, with access control on messages p. 9/26
Controling information flow Message-passing operating system, with access control on messages p. 9/26
Controling information flow Message-passing operating system, with access control on messages p. 9/26
Controling information flow Message-passing operating system, with access control on messages p. 9/26
Controling information flow Message-passing operating system, with access control on messages p. 9/26
p. 10/26 Related work Conventional multi-level security - Kernel-enforced information flow control across processes - A handful of levels and compartments: secret, nuclear - Inflexible, administrator-established policies - Central authority, no privilege delegation Language-enforced information flow (Jif) - Applications can define flexible policies at compile time - Enforced within one process Asbestos - Applications can define flexible policies - Kernel-enforced across all processes
p. 11/26 Asbestos labels Anybody can create a compartment dynamically - Achieved through 61-bit handles, unique until reboot, represented graphically by color - Labels map handles to sensitivity/integrity levels Specify policies such as P can t talk to Decentralized declassification Discretionary policies - Compartments can be used for integrity - Sanitization privileges for one compartment let you talk to a server in that compartment -... which is exactly a discretionary capability!
p. 12/26 Asbestos label notation A label is a function L : H Levels Example: L(h) = l 0 if h = h 0 l 1 if h = h 1 l 2 if h = h 2 l def otherwise Use more compact set-like notation to express this: {h 0 l 0, h 1 l 1, h 2 l 2, l def } - Last component (l def ) is level for all handles not explicitly listed
p. 13/26 Levels Handles are mapped to Levels = {, 0, 1, 2, 3} 3 represents contamination with secret data 2 default clearance level for all handles 1 default contamination level for all handles 0 high integrity / non-discretionary capabilities represents sanitization privileges
p. 14/26 Successes Built a new message passing operating system Asbestos label design - New security mechanism to track information flow control - Allow unprivileged processes to create & control compartments - Support application-defined policies Event process abstraction - Solves excess contamination problem of previous systems - Scales to thousands of compartments (previously impractical) OKWS web server version 2 - Vastly better security than version 1 (for Unix) - Achieves user isolation that wasn t possible on Unix - Acceptable performance and scalability
p. 15/26 Metrics Security - Contains even catastrophic bugs in CGI scripts - TCB still includes Database & network code Programmability - System proved usable for event-driven programmers - Kernel interface designed alongside application needs to be validated with other applications Performance - Acceptable performance - Room for improvement
p. 16/26 Security Labels prevent worker code from leaking others data Same label code enforces all security in system
p. 17/26 Security: Future work Applications need a persistent notion of compartments - Kernel-enforced compartments don t survive reboots - Requires user-level idd to map persistent data to ephemeral labels - Lack of persistence one source of complication Given persistence, could privilege-separate storage - E.g., Keykos-like file system w. one domain per file Better engineering of netd, etc. - Bulk of TCP implementation needn t be privileged Better control over covert channels
p. 18/26 Programmability Simpler to implement security than in Unix Example: OKWS version 1 (Unix) 1. Establish chroot directory 2. Obtain UID and GID ranges 3. Assign ith worker a unique UID and GID 4. Allocate a writable coredump directory for each UID 5. Change executables to correct group, mode 0410 6. Call chroot 7. Kill previous processes w. UID, start worker - Doing this requires system-wide root privleges
p. 19/26 Programmability 2 With Asbestos, easy to match labels to policy Example: OKWS 2 for Asbestos - idd has to create compartments, disseminate privilege as in previous picture - idd only possesses application-wide privileges - No need to worry about every potential interaction - Labels enforce isolation regardless of communication patterns
p. 20/26 Programmability: Future work Need another application - How easy is second application? - Need to re-write OKWS, distilling design patterns - Possible applications: red/green VPNs, wiki cgi, uploadable spam filters, file modification tracking,... Event-driven programming support - Can we apply language-level support research to Asbestos Debugging support - Need to understand label failures - Currently done by examining privileged console output
p. 21/26 Performance: Throughput Can get security with at most a small constant factor more hardware
p. 22/26 Performance: Scalability 1.5 4K-pages per cached session 9.5 4K-pages per active session
p. 23/26 Performance: Detail Label size is currently the scalability bottleneck
p. 24/26 Performance: Future work Improve label implementation - Through 9 label implementations, we have made significant progress If we need more performance, can change abstractions - Cost comes from processes with application-wide privilege - Could, for example, have hierarchical compartment names - But we see benefit from flat namespace encourages only transferring explicitly needed rights Other general performance improvements - E.g., network stack not competitive, bad concurrency
p. 25/26 Conclusions Asbestos explores new design point for secure OSes - MAC + fine-grained compartments + decentralized downgrading Preliminary results show suitability for Internet services - Usable performance - Good security without having to trust service (e.g., CGI) code Approach may enable new types of application - Red/green VPNs, uploadable spam filters, etc. Preliminary interest from industry
p. 26/26 Asbestos Project Home Page