Information Flow Control for Standard OS Abstractions Landon Cox April 6, 2016

Access control and the kernel What are the primary responsibilities of a kernel? Managing the file system Launching/scheduling processes Managing memory How do processes invoke the kernel? Via system calls Hardware shepherds transition from user process to kernel Processor knows when it is running kernel code Represents this through protection rings or mode bit

Access control and the kernel How does kernel know if system call is allowed? Looks are user id (uid) of process making the call Looks at resources accessed by call (e.g., file) Checks access-control policy associated with resource Decides if policy allows uid to access resources How is a uid normally assigned to a process? On fork, child inherits parent’s uid

MOO accounting problem Multi-player game called Moo Want to maintain high score in a file Should players be able to update score? Yes Do we trust users to write file directly? No, they could lie about their score High score Game client (uid y) Game client (uid y) Game client (uid x)

MOO accounting problem Multi-player game called Moo Want to maintain high score in a file Should players be able to update score? Yes Do we trust users to write file directly? No, they could lie about their score Could have a trusted process update scores Why isn’t this sufficient? Can’t be sure that reported score is genuine Also want to ensure that score was computed correctly High score Game client (uid y) Game client (uid y) Game client (uid x) Trusted process (root) Trusted process (root)

Access control Simple inheritance of uids is not sufficient for Tasks involving management of “user id” state Logging in (login) Changing passwords (passwd) Why isn’t this code just inside the kernel? This functionality doesn’t really require interaction w/ hardware Would like to keep kernel as small as possible How are “trusted” user-space processes identified? Run as super user or root (uid 0) Like a software kernel mode If a process runs under uid 0, then it has more privileges

Access control Why does login need to run as root? Needs to check username/password correctness Needs to fork/exec process under another uid Why does passwd need to run as root? Needs to modify password database (file) Database is shared by all users What makes passwd particularly tricky? Easy to allow process to shed privileges passwd requires an escalation of privileges Solution: setuid Executable files can have their setuid bit set If setuid bit is set, process inherits uid of image file’s owner on exec

MOO accounting problem Multi-player game called Moo Want to maintain high score in a file How does setuid allow us to know that score is correct? Game executable is owned by trusted entity Game cannot be modified by normal users Users can run executable though High-score is also owned by trusted entity This is a form of trustworthy computing High-score maintainer knows exactly which code will update score Ensures code integrity, even when run by untrusted users High score Game client (uid y) Game client (uid y) Game client (uid x)

Information Flow Control (IFC) Goal: track which secrets a process has seen Mechanism: each process gets a secrecy label Label summarizes which categories of data a process is assumed to have seen. Examples: { “Financial Reports” } { “HR Documents” } { “Financial Reports” and “HR Documents” } “tag” “label” Slide by Max Krohn

Secrecy, Integrity, and Privilege Secrecy label (S p ) Specifies what data P has read “/usr/bin/login may read the password file” Integrity label (I p ) Used to endorse trustworthiness of P “/usr/bin/login can only be updated by root” Also limits what P can read “/usr/bin/login can only read user libs and config files endorsed by root” Ownership (O p ) Regulates how P can update S p and I p Tags P can add to its labels (e.g., t + ), i.e., endorse via integrity label Tags P can remove from its labels (e.g., t - ), i.e., declassify via secrecy label D p is the set of tags that P can both add and remove What is an endorsement? Why is this restriction necessary? How did endorsements work in the Moo prob?

Secrecy, Integrity, and Privilege Secrecy “At some point process p added data with tag s to its address space.” s ∈ S p  ∃ (data) : p read data with tag s Integrity “All inputs to process p had tag i.” i ∈ I p  ∀ (data) : p read data with tag i Privilege “p can remove tag s from S p and add tag i to I p.” s ∈ t -  p is trusted to declassify s i ∈ t +  p is trusted to endorse i t ∈ D p  t ∈ t - and t ∈ t +

Tags + Secrecy Labels Process p tag_t HR = create_tag(); S p = {} D p = {} D p = { HR } Universe of Tags: Finance Legal SecretProjects change_label({Finance}); S p = { Finance }S p = { Finance, HR } HR change_label({Finance,HR}); change_label({Finance}); change_label({}); DIFC: Declassification in action. Same as Step 1. Any process can add any tag to its label. DIFC Rule: A process can create a new tag; gets ability to declassify it. Secrets P has viewed Tags P can add and remove from its label Slide by Max Krohn

Tags + Integrity Labels Process p I p = {Apple} D p = {} Universe of Tags: Finance Legal Apple change_label({}); Any process can remove any tag from its label. Slide by Max Krohn Endorsements of P Tags P can add and remove from its label

Tags + Integrity Labels Process p I p = {} D p = {} Universe of Tags: Finance Legal Apple change_label({}); Slide by Max Krohn

Tags + Integrity Labels Process p tag_t HR = create_tag(); D p = {} Universe of Tags: Finance Legal Apple change_label({}); I p = {} change_label({Microsoft}); Slide by Max Krohn

Tags + Integrity Labels Process p tag_t HR = create_tag(); D p = {} Universe of Tags: Finance Legal Apple change_label({}); I p = {} Slide by Max Krohn

Tags + Integrity Labels Process p tag_t HR = create_tag(); D p = {HR} Universe of Tags: Finance Legal Apple change_label({}); I p = {} Slide by Max Krohn HR DIFC Rule: A process can create a new tag; gets ability to endorse w/ it.

Tags + Integrity Labels Process p tag_t HR = create_tag(); D p = {HR} Universe of Tags: Finance Legal Apple change_label({}); I p = {} Slide by Max Krohn HR change_label({HR});

Tags + Integrity Labels Process p tag_t HR = create_tag(); D p = {HR} Universe of Tags: Finance Legal Apple change_label({}); I p = {HR} Slide by Max Krohn HR change_label({HR}); DIFC: Endorsement in action.

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = {} D p = { HR, Admin }

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = { HR } D p = { HR, Admin } Why is this allowed?

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = { HR } D p = { HR, Admin } What is the effect?

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = { HR } D p = { HR, Admin } What is the effect? Can now receive data from HR processes q q S q = { HR }

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = {} D p = { HR, Admin } Why is this allowed? q q S q = { HR }

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = {} D p = { HR, Admin } What is the effect? q q S q = { HR }

Privilege in action (secrecy) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p S p = {} D p = { HR, Admin } What is the effect? q q S q = { HR } r r S r = {} Declassifies HR data received from q

Privilege in action (integrity) Finance Legal SecretProjects HR Admin Bob’s code Alice’s code Microsoft Universe of Secrecy Tags: Universe of Integrity Tags Process p I p = {Admin} D p = { HR, Admin } Admin + makes p a certifier

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin}

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi”

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi” q q I p = {Admin} D p = { HR, Admin } fork()

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi” q q I p = {Admin} D p = { HR } fork() Why drop Admin + ?

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi” q q I p = {Admin} D p = { HR } fork() exec(“vi”) Should this work?

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi” q q I p = {Admin} D p = { HR } fork() load(“libc”)

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run vi” q q I p = {Admin} D p = { HR } fork() read(“/etc/rc”)

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run Fakevi”

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run Fakevi” q q I p = {Admin} D p = { HR, Admin } fork()

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run Fakevi” q q I p = {Admin} D p = { HR } fork()

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run Fakevi” q q I p = {Admin} D p = { HR } fork() exec(“fakevi”)

Privilege in action (integrity) Process p I p = {Admin} D p = { HR, Admin } vi I p = {Admin} libc I p = {Admin} Fake vi Fake vi I p = {} /etc/r c I p = {Admin} “Run Fakevi” q q I p = {Admin} D p = { HR } fork() exec(“fakevi”) Should this work?

Communication Rule Process qProcess p S q = { HR, Finance } S p = { HR }  p can send to q iff S p  S q Slide by Max Krohn

Flume Communication Rule 1.q changes to S q = { Alice } 2.p sends to q 3.q changes back to S q = {} MoinMoin (r) MoinMoin (p) S r = { Bob } S p = { Alice } Database (q) S q = {} D q = { Alice, Bob } ?? S p  S q S q = { Alice } D q = { Alice, Bob }  Slide by Max Krohn

Flume Communication Rule MoinMoin (r) MoinMoin (p) S r = { Bob } S p = { Alice } Database (q) S q = {} D q = { Alice, Bob }   Senders get extra latitude p can send to q iff: In IFC: S p  S q In Flume: S p – D p  S q  D q Slide by Max Krohn Receivers get extra latitude

Unexpected Program Behavior (Unreliable Communication) Process qProcess p “I stopped reading” “I crashed”  “Fire Alice, Bob, Charlie, Doug, Eddie, Frank, George, Hilda, Ilya…” Slide by Max Krohn

Unreliable communication Process p stdinstdout “Fire Alice, Bob, Charlie, Doug, Eddie, Frank, George, Hilda, Ilya…” “SLOW DOWN!!” “I crashed”  S q = { HR } ? S p = {} D p = { HR } Process q Slide by Max Krohn

New Abstraction: Endpoints f S f = { HR }S e = { HR } Process qProcess p S p = {} D p = { HR } e If S e  S f, then allow e to send to f If S f  S e, then allow f to send to e If S f = S e, then allow bidirectional flow If S e  S f, then allow e to send to f If S f  S e, then allow f to send to e If S f = S e, then allow bidirectional flow S q = { HR } “Fire Alice, Bob, Charlie, Doug, Eddie, Frank, George, Hilda, Ilya…” “SLOW DOWN!!” “I crashed”   Slide by Max Krohn

Thus p needs HR  D p Thus p needs HR  D p Endpoints Declassify Data Data enters process p with secrecy { HR } But p keeps its label S p = {} S e = { HR } Process p S p = {} D p = { HR } e Slide by Max Krohn

Endpoint Invariant For any tag t  S p and t  S e Or any tag t  S e and t  S p It must be that t  D p Process p e S p = { Finance } S e = { HR } D p = { Finance, HR} Export inf. Import inf. Slide by Max Krohn

Endpoints Labels Are Independent f g S f = { HR } S g = {} S e = { HR } Process qProcess p S q = { HR }S p = {} D p = { HR } e Slide by Max Krohn

Example App: MoinMoin Wiki Slide by Max Krohn

How Problems Arise… MoinMoin Wiki (100 kLOC) MoinMoin Wiki (100 kLOC) FreeTShirts LayoffPlans if not self.request.user.may.read(pagename): return self.notAllowedFault() if not self.request.user.may.read(pagename): return self.notAllowedFault() x43 Slide by Max Krohn

MoinMoin + DIFC Apache Web Server Apache Web Server MoinMoin Wiki (100 kLOC) MoinMoin Wiki (100 kLOC) FreeTShirts LayoffPlans Declassifier 1 kLOC UntrustedTrusted Slide by Max Krohn

FlumeWiki Apache MoinMoin (100 kLOC) FreeTShirts LayoffPlans Declassifier 1 kLOC Web Client GET /LayoffPlans?user=Intern&PW=abcd S={} S={ HR } reliable IPC file I/O Flume- Oblivious unconfined confined Slide by Max Krohn

Results Does Flume allow adoption of Unix software? 1,000 LOC launcher/declassifier 1,000 out of 100,000 LOC in MoinMoin changed Python interpreter, Apache, unchanged Does Flume solve security vulnerabilities? Without our knowing, we inherited two ACL bypass bugs from MoinMoin Both are not exploitable in Flume’s MoinMoin Does Flume perform reasonably? Performs within a factor of 2 of the original on read and write benchmarks Slide by Max Krohn

Limitations Bigger TCB than HiStar / Asbestos Linux stack (Kernel + glibc + linker) Reference monitor (~22 kLOC) Covert channels via disk quotas Confined processes like MoinMoin don’t get full POSIX API. spawn() instead of fork() & exec() flume_pipe() instead of pipe() Slide by Max Krohn

Summary DIFC is a challenge to Programmers Flume: DIFC in User-Level Preserves legacy software Complements today’s programming techniques MoinMoin Wiki: Flume works as promised Invite you to play around: Slide by Max Krohn