Access Control Jeff Chase Duke University

The need for access control Processes run programs on behalf of users. (“subjects”) Processes create/read/write/delete files. (“objects”) The OS kernel mediates these accesses. How should the kernel determine which subjects can access which objects? This problem is called access control or authorization (“authz”). It also encompasses the question of who is authorized to make a given statement. The concepts are general, but we can consider Unix as an initial example.

Identity in an OS (Unix) Every process has a security label that governs access rights granted to it by kernel. Abstractly: the label is a list of named attributes and values. An OS defines a space of attributes and their interpretation. Some attributes and values represent an identity bound to the process. Unix: e.g., userID: uid There is a special administrator uid==0 called root or superuser or su. Root “can do anything”: normal access checks do not apply to root. uid=“alice” Alice uid credentials Every Unix user account has an associated userID (uid). (an integer)

Labels and access control login shell tool foo login shell tool creat(“foo”) write,close open(“foo”) read owner=“alice” uid=“alice” uid=“bob” Should processes running with Bob’s userID be permitted to open file foo? Alice Bob Every system defines rules for assigning security labels to subjects (e.g., Bob’s process) and objects (e.g., file foo). Every system defines rules to compare the security labels to authorize attempted accesses.

Unix: setuid and login A process with uid==root may change its userID with the setuid system call. This means that a root process can speak for any user or act as any user, if it tries. This mechanism enables a system login process to set up a shell environment for a user after the user logs in (authenticates). This is a refinement of privilege. login shell tool log in setuid(“alice”), exec fork/exec uid=“alice” Alice A privileged login program verifies a user password and execs a command interpreter (shell) and/or window manager for a logged-in user. A user may then interact with a shell to direct launch of other programs. They run as children of the shell, with the user’s uid. (runs as root) (runs as alice)

Labels and access control login shell tool foo login shell tool log in setuid(“alice”), exec fork/exec creat(“foo”) write,close open(“foo”) read fork/exec setuid(“bob”), exec owner=“alice” uid=“alice” uid=“bob” Every file and every process is labeled/tagged with a user ID. A process inherits its userID from its parent process. A file inherits its owner userID from its creating process. A privileged process may set its user ID. Alice Bob log in

Labels and access control login shell tool foo login shell tool creat(“foo”) write,close open(“foo”) read owner=“alice” uid=“alice” uid=“bob” Should processes running with Bob’s userID be permitted to open file foo? Alice Bob Every system defines rules for assigning security labels to subjects (e.g., Bob’s process) and objects (e.g., file foo). Every system defines rules to compare the security labels to authorize attempted accesses.

Concept: reference monitor A reference monitor is a program that controls access to a set of objects by other programs. The reference monitor has a guard that checks all requests against an access control policy before permitting them to execute. subject requested operation “boundary” protected state/objects program Alic e guard identity

Requirements for a reference monitor 1.Isolation: the reference monitor is protected from tampering. 2.Interposition: the only way to access the objects is through the reference monitor: it can examine and/or reject each request. 3.Authentication: the reference monitor can identify the subject. subject requested operation “boundary” protected state/objects program Alic e guard identity

Reference monitor What is the nature of the isolation boundary? If we’re going to post a guard, there should also be a wall. Otherwise somebody can just walk in past the guard, right? subject requested operation “boundary” protected state/objects program Alic e guard identity

The kernel is a reference monitor No access to kernel state by user programs, except through syscalls. – Syscalls transfer control to code chosen by the kernel, and not by the user program that invoked the system call. The kernel can inspect all arguments for each request. The kernel knows which process issues each request, and it knows everything about that process. User programs cannot tamper with the (correct) kernel. – The kernel determines everything about how the machine is set up on boot, before it ever gives user code a chance to run. Later we will see how the kernel applies access control checks, e.g., to file accesses.

Another way to setuid login shell tool log in fork setuid(“alice”) exec fork exec(“sudo”) setuid bit set /usr/bin/sudo uid=“root” Alice Example: sudo program runs as root, checks user authorization to act as superuser, and (if allowed) executes requested command as root. fork exec(“tool) sudo The mode bits on a program file may be tagged to setuid to owner’s uid on exec*. This is called setuid bit. Some call it the most important innovation of Unix. It enables users to request protected ops by running secure programs. The user cannot choose the code: only the program owner can choose the code to run with the owner’s uid. Parent cannot subvert/control a child after program launch: a property of Unix exec*.

Unix setuid: recap login shell power open(“secret”) read, write… owner=“root” uid=“alice” Alice uid = “root” setuid(“alice”) exec fork secret exec(“power”) shell uid=“alice” power owner=“root” 755 (exec perm) setuid bit = true uid=“root”!!!! tool creat(“power”) write(…) chmod(+x,setuid=true) uid=“root” Root (admin/super user) Refine the privilege of this process (using setuid syscall). Amplify/escalate the privilege of processes running this trusted program (using setuid bit).

A trusted program: sudo login shell tool log in fork setuid(“alice”) exec fork/exec uid = 0 (root) uid=“root” Alice Example: sudo program runs as root, checks user authorization to act as superuser, and (if allowed) executes requested command as root. fork exec(“tool”) sudo xkcd.com “sudo tool” With great power comes great responsibility.

The secret of setuid The setuid bit can be seen as a mechanism for a trusted program to function as a reference monitor. E.g., a trusted program can govern access to files. – Protect the files with the program owner’s uid. – Make them inaccessible to other users. – Other users can access them via the trusted program. – But only in the manner permitted by the trusted program. – Example: “moo accounting problem” in 1974 paper (cryptic) What is the reference monitor’s “isolation boundary”? What protects it from its callers?

Reference monitor How does the guard decide whether or not to allow access? We need some way to represent access control policy. subject requested operation “boundary” protected state/objects program Alic e guard identity

Concept: access control matrix Alice Bob obj1obj2 RW R --- We can imagine the set of all allowed accesses for all subjects over all objects as a huge matrix. How is the matrix stored?

Concept: ACLs and capabilities Alice Bob obj1obj2 RW R --- How is the matrix stored? Capabilities: each subject holds a list of its rights and presents them as proof of access rights. In many systems, a capability is an unforgeable reference/token that confers specific rights to access a specific object. Access control list (ACL): each object stores a list of identifiers of subjects permitted to access it. capability list ACL

Concept: roles or groups Alice Bob wizardstudent yes no A role or group is a named set S of subjects. Or, equivalently, it is a named boolean predicate that is true for subject s iff s  S. Roles/groups provide a level of indirection that simplifies the access control matrix, and makes it easier to store and manage. roles, groups wizard student obj1obj2 objects RW R ---

Attributes and policies More generally, each subject/object is labeled with a list of named attributes with typed values (e.g., boolean). Generally, an access policy for a requested access is a boolean (logic) function over the subject and object attributes. name = “Alice” wizard = true Name = “obj1” access: wizard name = “Bob” student = true Name = “obj2” access: student

Unix file access mode bits

ACLs and Unix file access control “Vanilla Unix” supports a limited form of ACL – read/write/execute for owner/owning-group/other – Owner can grant access to other users. – But you can’t grant access to users not in owning-group unless you grant access to everyone. – Efficient, but not very expressive. It is an example of Discretionary Access Control (DAC). – Alice can write whatever she wants into her files, and give anyone she wants access to those files. DAC is vulnerable to information leakage. – What if Alice gives access to her secret file to Bob, and Bob makes a copy and gives access to Everyone? Can the system prevent that?

Mandatory Access Control (MAC) A MAC system enforces a system-wide information security policy. Requires information flow control: track process data accesses and disallow “unsafe” flows. E.g., if a process reads secret data, don’t let it write into a network socket that exports data out of the system. Classic example: – Compartmentalize (tag) data by topic/owner and secrecy level. – Track data flows and label all processes and files with the (compartment, level) pairs they have “seen” or “may contain”. – Grant subjects clearance for specific topics at specific levels. – Disallow flows that don’t comply with the policy.

Information flow and leakage P1 foo P2 creat(“foo”) write,close open(“foo”) read owner=“alice” uid=“alice” uid=“bob” Alice Bob bar creat(“foo”) write,close P2 File bar is tainted with Alice’s data, because process P2 read foo, and the data P2 wrote to bar could have contained information from foo. Information flow follows the arrows. How does a MAC system prevent this? Track information flow and disallow read access to bar by any process that does not also have access to foo. Or (alternatively) disallow writes of “tainted” data out of the system. Works for integrity too! (it’s a dual)

Classic MAC terminology Dorothy Denning 1976 Tags represent categories of information. The value of a label is a set of tags. A set of tags represents an information compartment. – Containing (potentially) information from multiple categories. The set of compartments/labels forms a lattice: – finite set of elements (e.g., compartments) – in a partial order (e.g., by subset relation / dominance) – with a join operator (e.g., to combine two labels) – and a lower bound called meet (e.g., a label for zero secrecy) – and a least upper bound (e.g., most secret, maximal join)

26 LATTICE STRUCTURES {ARMY, NUCLEAR, CRYPTO} Compartments and Categories {ARMY, NUCLEAR} {ARMY, CRYPTO} {NUCLEAR, CRYPTO} {ARMY} {NUCLEAR}{CRYPTO} {} [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

Lattice {A, N, C} {A, N} {A, C}{N, C} {A} {N}{C} {} Partial ordered finite set of elements (a poset). E.g., subsets of a finite set of tags, ordered by subset relation. Unique lower bound (meet) Unique least upper bound (join) Binary join operator. Set is closed under join.

Using labels P 1. Compare labels to block reads, so it never even sees the data. P 2. Allow the reads, modify its label to track “taint” by sensitive data, and compare labels to block writes that leak to untrusted channels. How to prevent an untrusted process from leaking secret data? P

Labels and flow {A, C} {A} {C} join operator e.g.,union P A read P C P P {A,C} write label S = {} S = S join {A} = {A} S = S join {C} = {A,C} We can track the flow in mutable labels as information moves.

Clearance and dominance {A, C} {A} {C} S  T  T dominates S P P No write down! S = {A,C} T = {A} If labels are fixed, we can use them to apply a safety check to ensure that information does not flow/leak/trickle “down” the lattice. A flow is safe iff it moves toward a dominating label.

Secrecy and integrity IFC/MAC works for both secrecy and integrity. – “Talk only if you’re willing to tell and I’m willing to listen.” For secrecy – An object label classifies the secrecy of its data. – A subject label grants clearance to read secret data. – Data flows only “up” (toward a dominating label). For integrity – An object label endorses/certifies the integrity of its data. – A subject label endorses the subject to produce trusted data. – Data flows only “down” (toward a dominated label).

Bell-LaPadula (BLP) model (secrecy) Unclassified Confidential Secret Top Secret can-flow dominance  [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

Bell-LaPadula (BLP) model (secrecy) Unclassified Confidential Secret Top Secret Axioms 1.No read up 2.No write down (“star” property) The labels in a BLP system represent object classifications and subject clearances. The system enforces mandatory access control to block read/write operations that violate safety. It applies to any lattice structure. We can prove inductively that the system never reaches an unsafe state.

Biba model (integrity) Garbage Suspicious Some Integrity High Integrity can-flow dominance  [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

Biba model (integrity) Garbage Suspicious Some Integrity High Integrity Axioms 1.No read down 2.No write up (“star” property) Biba is the dual of BLP for integrity. Labels represent levels of integrity for subjects and objects. Subjects may not corrupt objects with a higher integrity level, or access information from a lower integrity level.

36 LATTICE STRUCTURES Hierarchical Classes with Compartments TS S {A,B} {} {A} {B} product of 2 lattices is a lattice [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

37 LATTICE STRUCTURES Hierarchical Classes with Compartments S, {A,B} {} {A}{B} S, TS, {A,B} {} {A} {B} TS, [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

“Decentralized” IFC (DIFC) Barbara Liskov (MIT) / Andy Myers [SOSP 1997 and…] DIFC is a style of MAC/IFC in which users may define new tags, and control policy for their tags. – Users may tag their data. – Users control who can access their tagged data objects. – System propagates tags (IFC) and blocks unsafe flows (MAC). – Trusted programs may be granted authority for tags, allowing them to mark flows as safe, even if they violate classical IFC. – E.g., to endorse flows (to vouch for integrity of unsafe flows) or declassify flows (to vouch for their secrecy). New DIFC systems appear at major systems forums almost every year, e.g., Flume [SOSP 2007].

DIFC Authority Trusted subjects may have authority to perform certain privileged operations on labels. For secrecy 1.Add tag to a process label to enable it to read secret data (and prevent it from leaking that data). 2.Remove tag from a process label to enable it to write secret data to an unclassified destination. 3.Remove tag from data label to declassify data. Beware: Flume endpoints introduce multiple cases for #3.

DIFC Authority Trusted subjects may have authority to perform certain privileged operations on labels. For integrity 1.Add tag to a process label to block it from reading uncertified data (or loading uncertified code). 2.Add tag to a data label to endorse (certify) data. Beware: Flume endpoints introduce multiple cases for #2.

Flume [SOSP 2007] DIFC for Unix, no mainline kernel changes. – Secrecy and integrity labels + reference monitor – IFC at process grain: can’t track flows “inside” a process. All flows pass through channels with endpoints. – Channels are files, pipes, or sockets: streams. – An endpoint is a Unix file descriptor. Endpoints have labels. Flume API: – Create tags, control capabilities (authority) to operate on them. – Change labels for processes, endpoints, files: requires capabilities to modify affected tags. Label changes are always explicit. – Create a confined process (spawn) and control its labels and permissions, and/or pass it pipes and capabilities for tags.

Processes and endpoints A Flume process reads and writes data through endpoints. Endpoints may be readable, or writable, or both. S p = {…} pef D p = {…} S e = {…} I e = {…} S f = {…} Definition 4 (d4) defines conditions for a safe endpoint. Definition 5 (d5) defines conditions for safe flow. Endpoints have their own secrecy and integrity labels. Safe flows are defined between endpoints, based on their labels. I f = {…} I p = {…} By default an endpoint label is the same as the process label, but the process may change the endpoint label if it has permission. Adding or removing a tag from an endpoint label requires dual permission in D p.

Heart of Flume

What endpoint ops require privilege? Adding a tag to the secrecy label of a read endpoint (declassifies data on read) Removing a tag from the integrity label of a read endpoint (allows read of uncertified data) Removing a tag from the secrecy label of a write endpoint (declassifies data on write) Adding a tag to the integrity label of a write endpoint (certifies on write)

Safe and unsafe flows: scenarios We consider all the cases for data movement in or out of p. S p = {…} pef D p = {…} S e = {…} I e = {…} S f = {…} Definition 4 (d4) defines conditions for a safe endpoint. Definition 5 (d5) defines conditions for safe flow. It is sufficient to consider the conditions for reading and writing files. For IPC, the peer q must have the same permission as required to communicate through a file. (If p writes, then q reads, and vice versa.) The creator p of a file f assigns a label to f at create time. Process p may assign any label to f, as long as p is then permitted to write to f according to the rules. Once assigned the label of f is immutable. I f = {…} I p = {…}

Reading secret data Process p is tagged with t  S p : p has t-secret data. S p = {t} pef D p = {} S e = {t} S f = {t} d4 condition S e – S p  D p File f is tagged with t  S f : f contains t-secret data. Reads from p on f are safe. d5 condition S f  S e The flow is safe even if p is untrusted: p requires no authority to set up the endpoint e (D p ={}). It is safe because the data is still marked t-secret at the destination.    

Writing secret data Process p is tagged with t  S p : p has t-secret data. S p = {t} pef D p = {} S e = {t} S f = {t} d4 condition S p – S e  D p File f is tagged with t  S f : f contains t-secret data. Writes from p to f are safe. d5 condition S e  S f The flow is safe even if p is untrusted: p requires no authority to set up the endpoint e (D p ={}). It is safe because the data is still marked t-secret at the destination.    

Export protection Create secrecy tag t, give everyone a capability to add it: t+. Now any p can read t-secret data by adding t to its S p. But p cannot declassify t-secret data, because p lacks t  D p. Therefore p cannot leak t-secret data: p can read it and write it, but only to destinations that are also labeled as t-secret.

Blocking leakage of secret data Process p is tagged with t  S p : p has t-secret data. S p = {t} pef D p = {...} S e = {t} S f = {} d4 condition S p – S e  D p d5 condition S e  S f To write data, p must either label the destination f as also t-secret, or p must declassify the data on write (which requires dual privilege on t). File f is not tagged: t  S f : writes of t-secret data to f are unsafe. 

Alternative: read protection Create secrecy tag t, and label some data. Give a capability for t+ only to selected processes. Only processes p with t+ can read the data (by adding t to S p ). But p cannot declassify t-secret data if p lacks dual privilege: t  D p.

Blocking access to secret data Process p is not tagged with t  S p : reads of t-secret data are unsafe. S p = {} pef D p = {} S e = {} S f = {t} d4 condition S e – S p  D p d5 condition S f  S e To read from f, p must either tag the destination p as also t-secret, or p must declassify the data on read (which requires dual privilege for t). File f is tagged: t  S f : f contains t-secret data. Q: is it safe to allow any untrusted process to add t to its secrecy label in order to read this data? 

Writing declassified data Process p is tagged with t  S p : p has t-secret data. S p = {t} pef D p = {t} S e = {} S f = {} d4 condition S p – S e  D p File f is not tagged: t  S f : writes of t-secret data to f are unsafe. Endpoint e declassifies data as it is written: t  S e. d5 condition S e  S f Process p is trusted: p requires authority for t to make e (t  D p ). The flow requires trust in p because the data loses its t-secret tag.   

Reading declassified data S p = {} pef D p = {t} S e = {t} S f = {t} d4 condition S e – S p  D p d5 condition S f  S e   Process p is not tagged: t  S p : reads of t-secret data by p are unsafe. File f is tagged with t  S f : f contains t-secret data. Endpoint e declassifies data as it reads: t  S e. Process p is trusted: p requires authority for t to make e (t  D p ). The flow requires trust in p because the data loses its t-secret tag. 

Integrity protection Spawn a new process p marked with an integrity tag v  I p. Don’t give p any privilege for v. Now p can access only data and code that is certified for v.

Blocking uncertified reads I p = {v} pef D p = {} I e = {v} I f = {} d4 condition I e – I p  D p d5 condition I f  I e To read from f, p must either mark itself as not v-assured, or p must endorse the data on read (which requires dual privilege for v). Similarly, p cannot execute code from f without reducing p’s integrity.  File f is not tagged: v  I f : data from f is uncertified (not v-assured). Process p is tagged: v  I p : p is certified as v-assured.

Reading certified data I p = {v} pef D p = {} I e = {v} I f = {v} Reads from p on f are safe. The flow is safe even if p is untrusted: p requires no authority to set up the endpoint e (D p ={}). It is safe because the data (or code) is certified as v-assured, so it won’t corrupt p. The data is certified as safe even for a v-assured p. d4 condition I e – I p  D p d5 condition I f  I e   Process p is tagged: v  I p : p is certified as v-assured. File f is tagged: v  I f : f contains v-assured data.

Blocking uncertified writes I p = {} pef D p = {…} I e = {} I f = {v} d4 condition I e – I p  D p d5 condition I f  I e To write to f, p must either untag the destination f, or p must endorse the data on write (which requires dual privilege for v).  Process p is not tagged: v  I p : data from p is not certified as v-assured. File f is tagged: v  I f : f contains v-assured data.

Writing certified data I p = {v} pef D p = {} I e = {v} I f = {v} d4 condition I e – I p  D p d5 condition I f  I e  Process p is tagged: v  I p : data from p is trusted as v-assured. File f is tagged: v  I f : f contains v-assured data.  Writes from p to f are safe. The flow is safe because p is running v-assured code and all data it sees is v-assured: p requires no additional authority to set up the endpoint e (D p ={}).  

Endorsing data on write I p = {} pef D p = {v} I e = {v} I f = {v} d4 condition I e – I p  D p d5 condition I f  I e  File f is tagged: v  I f : f contains v-assured data.  Process p is not tagged: v  I p : data from p is not certified as v-assured. Endpoint e endorses data as it is written: v  I e. Process p is trusted: p requires authority for v to make e (v  D p ). The flow requires trust in p because the data gains a v-assured tag.

Endorsing data on read I p = {v} pef D p = {v} I e = {} I f = {} d4 condition I e – I p  D p d5 condition I f  I e  Process p is tagged: v  I p : p is certified as v-assured. File f is not tagged: v  I f : data from f is uncertified (not v-assured).  Endpoint e endorses data as it is read: v  I e. Process p is trusted: p requires authority for v to make e (v  D p ).

Flume: stuff to notice Example of capability model: processes hold capabilities for tags, and may transfer them through channels. – Tokens represent capabilities in transfer and storage. These are “hard to guess” values, also known as sparse capabilities. There’s lots of work in language-level IFC, but Flume doesn’t do it: no “taint tracking” within a process. Section restate BLP/Biba rules for safe flow. Reference monitor for confined processes by syscall interposition (spawn operator, through spawner server). – E.g., Linux Security Modules (LSM) Setlabel: mark trusted programs “like setuid [bit]”.

Reference monitors: three examples 1.The Kernel 2.Setuid bit: a mode bit on an executable program file indicating that the program always runs as its owner. – A process running that program always has the owner’s userID. – Exec* system call implementation retrieves the setuid bit and owner’s userID from the file’s inode, and sets the process userID if the setuid bit is set. 3.Server process (as in Flume) – Listens on a named port, accepts request from clients over sockets, and decides whether to allow or deny each request. For each example, what is the nature of the isolation boundary? For each example, how does it identify the subject?