Access Control Jeff Chase Duke University The need

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. uid=“alice” • Unix: e. g. , user. ID: uid Every Unix user account has an associated user. ID (uid). (an integer) credentials uid Alice 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.

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

Unix: setuid and login Alice • A process with uid==root may change its user. ID with the setuid system call. log in • This means that a root process can speak for any user or act as any user, if it tries. (runs as root) login setuid(“alice”), (runs as alice) exec shell fork/exec tool uid=“alice” • 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. 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.

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

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

Concept: reference monitor requested operation “boundary” Alice protected state/objects identity subject program guard 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.

Requirements for a reference monitor requested operation “boundary” Alice protected state/objects identity subject program guard 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.

Reference monitor requested operation “boundary” Alice protected state/objects identity subject program guard 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?

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 Alice • The mode bits on a program file may be tagged to setuid to owner’s uid on exec*. log in • This is called setuid bit. Some call it the most important innovation of Unix. login fork setuid(“alice”) exec fork exec(“sudo”) setuid bit set /usr/bin/sudo fork exec(“tool) shell sudo tool uid=“root” • 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*. Example: sudo program runs as root, checks user authorization to act as superuser, and (if allowed) executes requested command as root.

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

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

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 requested operation “boundary” Alice protected state/objects identity subject program guard How does the guard decide whether or not to allow access? We need some way to represent access control policy.

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

Concept: ACLs and capabilities How is the matrix stored? ACL obj 1 obj 2 Alice RW --- Bob R RW capability list • 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.

Concept: roles or groups roles, groups wizard objects student obj 1 obj 2 Alice yes no wizard RW --- Bob no yes student R RW • 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.

Attributes and policies name = “Alice” wizard = true Name = “obj 1” access: wizard name = “Bob” student = true Name = “obj 2” access: student • 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.

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 Bob Alice P 1 uid=“alice” creat(“foo”) write, close foo open(“foo”) read owner=“alice” File bar is tainted with Alice’s data, because process P 2 read foo, and the data P 2 wrote to bar could have contained information from foo. Information flow follows the arrows. P 2 uid=“bob” creat(“foo”) P 2 write, close bar 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 Compartments and Categories {ARMY, NUCLEAR, CRYPTO} {ARMY, NUCLEAR} {ARMY, CRYPTO} {ARMY} {NUCLEAR, CRYPTO} {} [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

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

Using labels How to prevent an untrusted process from leaking secret data? 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. P

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

Clearance and dominance 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, C} {A} SÍ T T dominates S {C} A flow is safe iff it moves toward a dominating label. S = {A, C} P P T = {A} No write down!

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-La. Padula (BLP) model (secrecy) Top Secret Confidential Unclassified dominance can-flow [Ravi Sandhu, Lattice-Based Access Control Models, 1993]

Bell-La. Padula (BLP) model (secrecy) Axioms 1. No read up 2. No write down (“star” property) Top Secret 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. Confidential Unclassified

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

Biba model (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. High Integrity Some Integrity Suspicious Garbage

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

37 LATTICE STRUCTURES TS, {A, B} TS, {A} Hierarchical Classes with Compartments TS, {} S, {A, B} S, {A} S, {B} S, {} [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 p Sp = {…} Ip = {…} e Se = {…} Ie = {…} Dp = {…} f Sf = {…} If = {…} Definition 4 (d 4) defines conditions for a safe endpoint. Definition 5 (d 5) defines conditions for safe flow. A Flume process reads and writes data through endpoints. Endpoints may be readable, or writable, or both. Endpoints have their own secrecy and integrity labels. Safe flows are defined between endpoints, based on their labels. 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 Dp.

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 secrecy label of a write endpoint (declassifies data on write) Removing a tag from the integrity label of a read endpoint (allows read of uncertified data) Adding a tag to the integrity label of a write endpoint (certifies on write)

Safe and unsafe flows: scenarios p Sp = {…} Ip = {…} e Se = {…} Ie = {…} Dp = {…} f Definition 4 (d 4) defines conditions for a safe endpoint. Sf = {…} If = {…} Definition 5 (d 5) defines conditions for safe flow. We consider all the cases for data movement in or out of p. 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.

Reading secret data p e P Sp = {t} f d 4 condition S e – S p Í Dp Se = {t} Dp = {} Sf = {t} d 5 condition Sf Í S e P P Process p is tagged with tÎ Sp: p has t-secret data. File f is tagged with tÎ Sf: f contains t-secret data. Reads from p on f are safe. P The flow is safe even if p is untrusted: p requires no authority to set up the endpoint e (Dp={}). It is safe because the data is still marked t-secret at the destination.

Writing secret data p e P Sp = {t} f d 4 condition S p – S e Í Dp Se = {t} Dp = {} Sf = {t} d 5 condition Se Í S f P P Process p is tagged with tÎ Sp: p has t-secret data. File f is tagged with tÎ Sf: f contains t-secret data. Writes from p to f are safe. P The flow is safe even if p is untrusted: p requires no authority to set up the endpoint e (Dp={}). 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 Sp. • But p cannot declassify t-secret data, because p lacks t Î Dp. • 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 p e f d 4 condition S p – S e Í Dp Sp = {t} Se = {t} Dp = {. . . } Sf = {} P d 5 condition Se Í S f Process p is tagged with tÎ Sp: p has t-secret data. File f is not tagged: t Ï Sf: writes of t-secret data to f are unsafe. 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).

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 Sp). • But p cannot declassify t-secret data if p lacks dual privilege: t Î Dp.

Blocking access to secret data p e f d 4 condition S e – S p Í Dp Sp = {} Se = {} Dp = {} Sf = {t} P d 5 condition Sf Í S e File f is tagged: t Î Sf: f contains t-secret data. Process p is not tagged with t Î Sp: reads of t-secret data are unsafe. 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). 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 p e Sp = {t} P f d 4 condition S p – S e Í Dp Se = {} Dp = {t} Sf = {} d 5 condition Se Í S f Process p is tagged with t Î Sp: p has t-secret data. File f is not tagged: t Ï Sf: writes of t-secret data to f are unsafe. Endpoint e declassifies data as it is written: t Ï Se. Process p is trusted: p requires authority for t to make e (t Î Dp). The flow requires trust in p because the data loses its t-secret tag. P P

Reading declassified data p e Sp = {} P f d 4 condition S e – S p Í Dp Se = {t} Dp = {t} Sf = {t} d 5 condition Sf Í S e P P File f is tagged with t Î Sf: f contains t-secret data. Process p is not tagged: t Ï Sp: reads of t-secret data by p are unsafe. Endpoint e declassifies data as it reads: t Î Se. Process p is trusted: p requires authority for t to make e (t Î Dp). 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 Î Ip. • Don’t give p any privilege for v. • Now p can access only data and code that is certified for v.

Blocking uncertified reads p e f d 4 condition I e – I p Í Dp Ip = {v} Ie = {v} Dp = {} If = {} d 5 condition If Í I e Process p is tagged: v Î Ip: p is certified as v-assured. File f is not tagged: v Ï If: data from f is uncertified (not v-assured). 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. P

Reading certified data p e f d 4 condition I e – I p Í Dp Ip = {v} Ie = {v} Dp = {} If = {v} d 5 condition If Í I e P P Process p is tagged: v Î Ip: p is certified as v-assured. File f is tagged: v Î If: f contains v-assured data. 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 (Dp={}). 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.

Blocking uncertified writes p e f d 4 condition I e – I p Í Dp Ip = {} Ie = {} Dp = {…} If = {v} P d 5 condition If Í I e File f is tagged: v Î If: f contains v-assured data. Process p is not tagged: v Ï Ip: data from p is not certified as v-assured. 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).

Writing certified data p e P Ip = {v} f d 4 condition I e – I p Í Dp Ie = {v} Dp = {} If = {v} d 5 condition If Í I e File f is tagged: v Î If: f contains v-assured data. Process p is tagged: v Î Ip: data from p is trusted as v-assured. Writes from p to f are safe. P 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 (Dp={}). P P

Endorsing data on write p e f d 4 condition I e – I p Í Dp Ip = {} Ie = {v} Dp = {v} If = {v} d 5 condition If Í I e P P File f is tagged: v Î If: f contains v-assured data. Process p is not tagged: v Ï Ip: data from p is not certified as v-assured. Endpoint e endorses data as it is written: v Ï Ie. Process p is trusted: p requires authority for v to make e (v Î Dp). The flow requires trust in p because the data gains a v-assured tag.

Endorsing data on read p e f d 4 condition I e – I p Í Dp Ip = {v} Ie = {} Dp = {v} If = {} d 5 condition If Í I e Process p is tagged: v Î Ip: p is certified as v-assured. File f is not tagged: v Ï If: data from f is uncertified (not v-assured). Endpoint e endorses data as it is read: v Ï Ie. Process p is trusted: p requires authority for v to make e (v Î Dp). P 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 3. 1+3. 3 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 user. ID. – Exec* system call implementation retrieves the setuid bit and owner’s user. ID from the file’s inode, and sets the process user. ID 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?