1 labels and event processes in the asbestos operating system petros efstathopoulos * maxwell krohn...

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

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

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

The Problem

● If Bob compromises the system, he can access Alice's data

/submit_order.cgi

Alice123 Main St.4275-8204-4009-7915

Kernel

Bob456 Elm St.5829-7640-4607-1273

5

The Problem


/submit_order.cgi

Kernel

Alice123 Main St.4275-8204-4009-7915Bob456 Elm St.5829-7640-4607-1273

6

The Problem


/submit_order.cgi

Kernel


Alice123 Main St.4275-8204-4009-7915

7

The Problem


/submit_order.cgi

Kernel


Alice123 Main St.4275-8204-4009-7915

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

Virtual Machine Isolation

/submit_order.cgi

Kernel

/submit_order.cgi

Kernel

VMM

Alice123 Main St.4275-8204-4009-7915

Bob456 Elm St.5829-7640-4607-1273

10

Virtual Machine Tradeoffs

+ Strict partitioning of off-the-shelf software

+ But…– Coarse-grained sharing– Resource challenges

● Isolation should be an OS feature

11

Desired Behavior

/submit_order.cgi

Kernel


12

Desired Behavior

/submit_order.cgi

Kernel


Alice123 Main St.4275-8204-4009-7915

13

Desired Behavior

/submit_order.cgi

Kernel


Alice123 Main St.4275-8204-4009-7915

14

Information Flow Control

● Information flow control solves this kind of problem

/submit_order.cgi

Kernel


15


/submit_order.cgi

Kernel

Label data with its owner (contaminatewith respect to its owner)


16


/submit_order.cgi

Kernel

Keep track of who the connection is for


17


/submit_order.cgi

Kernel


18


/submit_order.cgi

Kernel


Alice123 Main St.4275-8204-4009-7915

Track the information as it moves around the operatingsystem

19


/submit_order.cgi

Kernel

Base access control decisionson labels Alice

123 Main St.4275-8204-4009-7915Bob456 Elm St.5829-7640-4607-1273

Alice123 Main St.4275-8204-4009-7915

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

Approaches

Within a process Across processes

Polic

y d

efined

by:

Ap

plic

ati

on

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-

Secr

et

Kern

el

Conventional MLS

Asbestos

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

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

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

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

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Send Label

Recv Label

Bob's ahttpd

BackendDB

27

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

28

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Rule 1:The kernel contaminates the message with all of the sender's contamination

Send Label

Recv Label

29

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Rule 2:The kernel validates that the destination has clearance to receive the contamination of the messageSend

Label

Recv Label

30

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Rule 3:At delivery, the destination takes on the contamination of the message

Send Label

Recv Label

31

Basic Example

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

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

vv

v

33

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

34

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

35

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

36

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

37

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

38

Limiting Bug Impact

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

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

Compartment Creation

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

41


Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

password

42


Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

passwordpassword

43


Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Any process that creates acompartment gets privilege with respect to that compartment:

Declassify dataGrant clearanceDelegate privilege

Send Label

Recv Label

44

Declassify Receive

Alice's ahttpd

User

Kernel

Bob's ahttpd

BackendDB

cgi script

Send Label

Recv Label

45

Optional Labels

● Process can attach optional (discretionary) labels to messages

– CS – Contaminate Send– DR – Declassify Receive– DS – Declassify Send– V – Verify

46

Declassify Receive

Alice's ahttpd

User

Kernel

Bob's ahttpd

BackendDB

DR =

cgi script

Declassify receivegrants clearance fora compartment toanother process

Send Label

Recv Label

47

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

The kernel checksthat processes havethe privilege neededto grant clearance

Send Label

Recv Label

DR=

48

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

Send Label

Recv Label DR=

49

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

Send Label

Recv Label

50

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

Send Label

Recv Label

51

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

Send Label

Recv Label

52

Declassify Receive

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

53

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

Send Label

Recv Label

54

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

No privilege needed for CS – it can only add processes to a compartment

Send Label

Recv Label

CS=

55

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

Send Label

Recv Label

56

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

Send Label

Recv Label

57

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

Send Label

Recv Label

58

Contaminate Send

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

CS =

Send Label

Recv Label

59

CGI Setup

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

DR =

Send Label

Recv Label

60

Bob Setup

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

61

Bob Setup

Alice's ahttpd

cgi script

User

Kernel

Bob's ahttpd

BackendDB

Application Trust

Send Label

Recv Label

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

Declassification

Alice's ahttpd

Alice's profiledeclassifier

User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

64

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

DR =DS=

Send Label

Recv Label

The process must have privilege for thecompartment to useboth DS and DR

65

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

66

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

profile

67

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

profile

68

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

profile

69

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

Since the process is privileged in Alice'scompartment, it doesn'tget contaminated

profile

70

Declassification

Alice's ahttpd


User

Kernel

Bob's ahttpd

BackendDB

Send Label

Recv Label

profile

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

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

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

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

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

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

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

Event Process Messages

Alice'sevent

process

Event process created port = existing session

CGIscript

● 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


Alice'sevent

process

Port created before ep_checkpoint() = new session

CGIscript

● Create a new event process

● Clone the address space & send and receive labels

● Event process must create a new port

DR=

80


Alice'sevent

process

CGIscript




Bob'sevent

process


DR=

81


Alice'sevent

process

CGIscript




Bob'sevent

process


DR=

82


Alice'sevent

process

CGIscript




Bob'sevent

process


83


Alice'sevent

process

CGIscript




Bob'sevent

process


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

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

worker_N

worker_1

Web Server Architecture

Database

netd demux ahttpd-idd

db-proxyworker_1

worker1

worker_NworkerN

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

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

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

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

● For 16 sessions, 150% of Apache

● For 10,000 session, 75% of Apache

Good Throughput

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

Future Work

● Minimizing label costs

● Easing programmability

● Label persistence

● More applications

94

Related Work

● Inspired by Jif

● Dynamic labels: IX, LOMAC

● Integrity: Biba

● Capabilities: KeyKOS, EROS

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

1 labels and event processes in the asbestos operating system petros efstathopoulos * maxwell krohn...

Documents

kernel alice

kernel bob

kernel vmm alice

inappropriate slide

owner alice

kernel label data

alices permission alice

exposed data