Download presentation
Presentation is loading. Please wait.
1
1 Labels and Event Processes in the Asbestos Operating System Petros Efstathopoulos * Maxwell Krohn † Steve VanDeBogart * Cliff Frey † David Ziegler † Eddie Kohler * David Mazières ‡ Frans Kaashoek † Robert Morris † * UCLA † MIT ‡ Stanford http://asbestos.cs.ucla.edu
2
2 Target Application E-commerce web server ● Thousands of users ● Users change quickly ● Necessarily reachable ● Historically vulnerable – PayMaxx divulged social security numbers – Stanford 10,000 recommendation letters – CardSystems exposed 40 million credit card numbers
3
3 What's the Problem? ● Bugs in web server or web application ● Many types of bugs allow access to server data – Buffer overflows – Missing access check – SQL injection ● It's nearly impossible to eliminate all bugs ● Want to minimize exposed data despite bugs ● Traditional OSs don't provide appropriate security mechanisms for this
4
4 The Problem ● If Bob compromises the system, he can access Alice's data /submit_order.cgi Alice 123 Main St. 4275-8204-4009-7915 Kernel Bob 456 Elm St. 5829-7640-4607-1273
5
5 The Problem ● If Bob compromises the system, he can access Alice's data /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
6
6 The Problem ● If Bob compromises the system, he can access Alice's data /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915
7
7 The Problem ● If Bob compromises the system, he can access Alice's data /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915
8
8 The Goal: User Isolation ● Bob should not be able to access Alice's data without Alice's permission – Alice and Bob’s data is isolated ● Complications – Even if there are bugs in the applications – Alice's data may travel through several processes ● To isolate, must prevent inappropriate data flow ● Application designer defines inappropriate
9
9 Virtual Machine Isolation /submit_order.cgi Kernel /submit_order.cgi Kernel VMM Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
10
10 Virtual Machine Tradeoffs Strict partitioning of off-the-shelf software But… – Coarse-grained sharing – Resource challenges ● Isolation should be an OS feature
11
11 Desired Behavior /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
12
12 Desired Behavior /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915
13
13 Desired Behavior /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915
14
14 Information Flow Control ● Information flow control solves this kind of problem /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
15
15 Information Flow Control /submit_order.cgi Kernel Label data with its owner (contaminate with respect to its owner) Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
16
16 Information Flow Control /submit_order.cgi Kernel Keep track of who the connection is for Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
17
17 Information Flow Control /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273
18
18 Information Flow Control /submit_order.cgi Kernel Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915 Track the information as it moves around the operating system
19
19 Information Flow Control /submit_order.cgi Kernel Base access control decisions on labels Alice 123 Main St. 4275-8204-4009-7915 Bob 456 Elm St. 5829-7640-4607-1273 Alice 123 Main St. 4275-8204-4009-7915
20
20 Information Flow Control Systems ● 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
21
21 Approaches Within a processAcross processes Policy defined by: Application Determining MAC Access The functionality provided by the interfaces to support MAC is used to determine the access of objects by subjects. The POSIX.6 standard defines a subject to be an active entity that can cause information to flow between controlled objects. The POSIX.6 standard further specifies that since processes are the only such interface-visible element of both the POSIX.1 and POSIX.6 standards, processes are the only subjects treated in POSIX.6 MAC. Objects are defined by POSIX.6 as the interface-visible data containers, i.e., entities that receive or contain data to which MAC is applied. POSIX.6 specifies that objects are files (this includes regular files, directories, FIFO-special files, and unnamed pipes), and processes (in cases where a process is the target of some request by another process). POSIX.6 also specifies that each subject and object shall have a MAC label associated with it at all times. The POSIX.6 standard does not define a mandatory access control policy perse, but does define the restrictions for access based upon the comparison of the MAC label associated with the subject and the MAC label associated with the object. The first general restriction states that unprivileged processes (subjects) cannot cause information labeled at some MAC label (L1) to become accessible to processes at MAC label (L2) unless L2 dominates L1 (see Section 4.6.2 for the definition of ``dominates''). This restriction is further defined with regard to accessing files and other processes. The restrictions placed on file manipulation (reading, writing, creating, etc.) are those that are generally accepted when implementing a MAC policy: 1. to read a file, the label of the process must dominate the label of the file. 2. to write to a file, the label of the process must be dominated by the label of the file (The POSIX.6 standard specifies that dominance equals equivalence - if the labels are equal, then each is considered to be dominant to the other). For example, a user who is running a process at Secret should not be allowed to read a file with a label of Top Secret. Conversely, a user who is running a process with a label of Secret should not be allowed to write to a file with a label of Confidential. The POSIX.6 restriction for assigning labels to newly created files is that the new file must have a label that is dominant to the label of the subject, although the POSIX.6 interfaces only allow the label to be equal to that of the process creating the new object. This restriction forces The POSIX.6 restriction for assigning labels to newly created files is that the new file must have a label that is dominant to the label of the subject, although the POSIX.6 interfaces only allow the label to be equal to that of the process creating the new object. This restriction forces implementations to not allow processes to create files at a ``lower'' label. For example, a process with a label of Top Secret should not be allowed to create a file with a label of Secret. There are analogous restrictions on object access when the object is a process as mentioned above. Top-Secret Kernel Conventional MLS Asbestos
22
22 Asbestos Contributions ● New message passing operating system – Requires rewrite of applications for new security mechanism ● Asbestos labels – New security mechanism to track information flow control – Designed to support application defined policies ● Event processes – A new process abstraction – Prevent accumulation of contamination ● Good performance – Wrote a web server that uses Asbestos labels & event processes – Acceptable performance with strong security properties up to at least 10,000 sessions
23
23 Asbestos Compartments ● A compartment is a kind of contamination / label type ● Example has two compartments: Alice & Bob ● Alice might have multiple compartments – Financial secrets – Romantic secrets ● Compartments can overlap ● Application defines compartment policy – Kernel enforces policy
24
24 Asbestos Labels Build Flexible Applications ● Application can create compartments without privilege – Application created users are isolated with the same mechanism as login users – Applications can easily sub-divide privilege ● Applications can delegate rights for compartments – Decentralized declassification like Jif ● Applications can choose different policies – Mandatory Access Control – Discretionary Access Control – Capabilities – More...
25
25 Label Basics ● Each process has a send and receive label – The send label tracks current contamination – The receive label tracks contamination limits (clearance) Rules track information flow Similar to IX
26
26 Basic Example Alice's ahttpd cgi script User Kernel Send Label Recv Label Bob's ahttpd Backend DB
27
27 Basic Example Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
28
28 Basic Example Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Rule 1: The kernel contaminates the message with all of the sender's contamination Send Label Recv Label
29
29 Basic Example Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Rule 2: The kernel validates that the destination has clearance to receive the contamination of the message Send Label Recv Label
30
30 Basic Example Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Rule 3: At delivery, the destination takes on the contamination of the message Send Label Recv Label
31
31 Basic Example Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
32
32 Implementing Clearance Checks ● How does the clearance check work? ● Labels form a lattice ● Partial ordering – Sender's send label must be less than or equal to the destination's receive label ● Send label updated with a least upper bound operator v v v v
33
33 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
34
34 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
35
35 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
36
36 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
37
37 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
38
38 Limiting Bug Impact Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
39
39 Application Defined Policies ● Where did the compartments come from? ● How did the labels get set the way they are? ● In traditional multi-level security systems, the system operator does these things ● Asbestos labels provide a decentralized and unprivileged method to set these initial conditions
40
40 Compartment Creation Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
41
41 Compartment Creation Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label password
42
42 Compartment Creation Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label password
43
43 Compartment Creation Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Any process that creates a compartment gets privilege with respect to that compartment: Declassify data Grant clearance Delegate privilege Send Label Recv Label
44
44 Declassify Receive Alice's ahttpd User Kernel Bob's ahttpd Backend DB cgi script Send Label Recv Label
45
45 Optional Labels ● Process can attach optional (discretionary) labels to messages – C S – Contaminate Send – D R – Declassify Receive – D S – Declassify Send – V – Verify
46
46 Declassify Receive Alice's ahttpd User Kernel Bob's ahttpd Backend DB D R = cgi script Declassify receive grants clearance for a compartment to another process Send Label Recv Label
47
47 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = The kernel checks that processes have the privilege needed to grant clearance Send Label Recv Label DR=DR=
48
48 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = Send Label Recv Label DR=DR=
49
49 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = Send Label Recv Label
50
50 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = Send Label Recv Label
51
51 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = Send Label Recv Label
52
52 Declassify Receive Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
53
53 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = Send Label Recv Label
54
54 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = No privilege needed for C S – it can only add processes to a compartment Send Label Recv Label CS=CS=
55
55 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = Send Label Recv Label
56
56 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = Send Label Recv Label
57
57 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = Send Label Recv Label
58
58 Contaminate Send Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB C S = Send Label Recv Label
59
59 CGI Setup Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB D R = Send Label Recv Label
60
60 Bob Setup Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Send Label Recv Label
61
61 Bob Setup Alice's ahttpd cgi script User Kernel Bob's ahttpd Backend DB Application Trust Send Label Recv Label
62
62 Declassification ● Information flow control keeps users data completely disjoint ● Alice wants to export some of her data, like her profile – But all her data is in her compartment ● How can she safely declassify her data? ● Alice must trust all process that can do so ● To minimize declassification bugs, we build declassifiers as simple, single purpose programs
63
63 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label
64
64 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB D R = DS=DS= Send Label Recv Label The process must have privilege for the compartment to use both D S and D R
65
65 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label
66
66 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label profile
67
67 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label profile
68
68 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label profile
69
69 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label Since the process is privileged in Alice's compartment, it doesn't get contaminated profile
70
70 Declassification Alice's ahttpd Alice's profile declassifier User Kernel Bob's ahttpd Backend DB Send Label Recv Label profile
71
71 Other Label Features Other label details and features only in the paper ● Verify label on messages – Allows a process to prove it has labels at specific levels ● Integrity tracking – Enabled by level 0 ● Different default level for send & receive labels – Enables interesting isolation policies
72
72 Label Implementation ● Contamination & Privilege = Label level (*, 0-3) ● = {A *, B 3, 1} ● A & B are compartment names ● Trailing 1 = Neutral in all other compartments – Including those that haven't been created yet ● Label representation linear in # compartments
73
73 Combating Process Over-Contamination ● One process per user per service – Lots of heavy weight context switches – Lots of memory ● Combine processes to get one process per service? – Become too contaminated to function – Or too privileged ● Many processes are similar ● Programming style help?
74
74 Event Loop while (1) { event = get_next_event(); user = lookup_user(event); if (user not yet seen) user.state = create_state(); process_event(event, user); } ● State isolated to data structures ● Stack not used from event to event ● Execution state has nice preemption points
75
75 Event Process Abstraction ep_checkpoint(&msg); if (!state.initialized) { initialize_state(&state); state.reply = new_port(); } process_message(&msg, &state); ep_yield(); // revert to chkpointed memory ● Fork memory state for each new session – Memory isolation is the same as fork – Small differences anticipated, stored efficiently (diff) ● Event loop allows shared execution state – Allows light weight context switches
76
76 Where's the fork? ● Explicit fork would be a covert channel – A process with a secret, N, can create N new sessions ep_checkpoint(&msg); if (!state.initialized) { new_sessions++; fork_memory(&state); state.reply = new_port(); } process_message(&msg, &state); ep_yield(); ● Combine memory-fork with message reception ● Fork when the message is for a new session
77
77 Communication Terms ● Communication end points are “ports” – Similar to Mach ports ● One process has receive rights for a port – Process with receive rights considered the current owner of the port
78
78 Event Process Messages Alice's event process Event process created port = existing session CGI script ● Choose the event process based on the owner of the destination port ● Restore any address space modifications ● Use the send and receive label specific to the event process
79
79 Event Process Messages Alice's event process Port created before ep_checkpoint() = new session CGI script ● Create a new event process ● Clone the address space & send and receive labels ● Event process must create a new port DR=DR=
80
80 Event Process Messages Alice's event process CGI script ● Create a new event process ● Clone the address space & send and receive labels ● Event process must create a new port Bob's event process Port created before ep_checkpoint() = new session DR=DR=
81
81 Event Process Messages Alice's event process CGI script ● Create a new event process ● Clone the address space & send and receive labels ● Event process must create a new port Bob's event process Port created before ep_checkpoint() = new session DR=DR=
82
82 Event Process Messages Alice's event process CGI script ● Create a new event process ● Clone the address space & send and receive labels ● Event process must create a new port Bob's event process Port created before ep_checkpoint() = new session
83
83 Event Process Messages Alice's event process CGI script ● Create a new event process ● Clone the address space & send and receive labels ● Event process must create a new port Bob's event process Port created before ep_checkpoint() = new session
84
84 Event Processes Work ● Event process isolate state – Used so that each event process is only contaminated by one user – One process per service with one event process per user ● Even at 10,000 event processes, state is stored efficiently ● Little additional programmer overhead because event processes fit into event driven programming style
85
85 It Works! ● Built it for x86 ● Uses the e1000 network driver from Linux ● LWIP network stack & SQLite database as a backend for the web server ● Built OKWS like web server
86
86 worker_N worker_1 Web Server Architecture Database netddemuxahttpd-idd db-proxy worker_1 worker1 worker_N workerN
87
87 Performance Hypotheses ● Is the memory overhead from event processes mild, even at 10,000 sessions? ● Despite better security properties, is the performance of the OK web server on Asbestos comparable with Apache? ● Does the per connection kernel overhead increase at most linearly with the number of sessions?
88
88 Experimental Setup – Memory /shopping_cart.cgi Hmm ● Active session – Adding an item to the shopping cart ● Cached session – Deciding if you really want an item ● How much memory do event processes use? ● Shopping cart application – Session state stored in event process – One event process per user Click!
89
89 Event Processes Conserve Memory ● Includes user and kernel memory ● Not too many active sessions on a large website 1.45 pages/session 9.48 pages/session
90
90 Experimental Setup – Throughput ● Simple character generation service – Not interested in application overhead – One event process per session (user) ● Compare to Apache & Mod-Apache – Varied concurrency to get best case performance ● Apache – Service runs as a CGI script – Connections are isolated into processes – Processes are not isolated or jailed on the system ● Mod-Apache – Service runs inside Apache process
91
91 ● For 16 sessions, 150% of Apache ● For 10,000 session, 75% of Apache Good Throughput
92
92 Label Cost Linear in Label Size ● Label cost starts small but outstrips OKWS cost around 6500 sessions ● Declassifiers label size O(#sessions) ● Throughput benchmark ● DB performance fixed
93
93 Future Work ● Minimizing label costs ● Easing programmability ● Label persistence ● More applications
94
94 Related Work ● Inspired by Jif ● Dynamic labels: IX, LOMAC ● Integrity: Biba ● Capabilities: KeyKOS, EROS
95
95 Conclusion ● Asbestos labels make MAC more practical – Labels provide decentralized compartment creation & privilege – Event processes avoid accumulation of contamination ● The OK web server on Asbestos – Performs comparably to Apache – Provides better security properties than Apache
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.