Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Published byRudolf Stanley Modified over 8 years ago

Similar presentations

Presentation on theme: "Information Flow Control for Standard OS Abstractions Landon Cox April 6, 2016."— Presentation transcript:

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

2 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

3 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

4 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)

5 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)

6 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

7 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

8 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)

9 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

10 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?

11 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 +

12 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

13 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

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

15 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

16 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

17 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.

18 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});

19 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.

20 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 }

21 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?

22 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?

23 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 }

24 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 }

25 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 }

26 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

27 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

28 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}

29 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”

30 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()

31 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 + ?

32 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?

33 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”)

34 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”)

35 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”

36 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()

37 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()

38 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”)

39 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?

40 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

41 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

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 Example App: MoinMoin Wiki Slide by Max Krohn

50 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

51 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

52 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

53 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

54 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

55 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: http://flume.csail.mit.edu Slide by Max Krohn

Download ppt "Information Flow Control for Standard OS Abstractions Landon Cox April 6, 2016."

Similar presentations

Information Flow Control For Standard OS Abstractions Max Krohn, Alex Yip, Micah Brodsky, Natan Cliffer, Frans Kaashoek, Eddie Kohler, Robert Morris.

Information Flow Control For Standard OS Abstractions Max Krohn, Alex Yip, Micah Brodsky, Natan Cliffer, Frans Kaashoek, Eddie Kohler, Robert Morris.
Operating System Security

Operating System Security
1 Information Security – Theory vs. Reality 0368-4474-01, Winter 2011 Lecture 7: Information flow control Eran Tromer Slides credit: Max Krohn, MIT Ian.

1 Information Security – Theory vs. Reality , Winter 2011 Lecture 7: Information flow control Eran Tromer Slides credit: Max Krohn, MIT Ian.
Chapter 6 Security Kernels.

Chapter 6 Security Kernels.
Access Control Jeff Chase Duke University. The need for access control Processes run programs on behalf of users. (“subjects”) Processes create/read/write/delete.

Access Control Jeff Chase Duke University. The need for access control Processes run programs on behalf of users. (“subjects”) Processes create/read/write/delete.
Title of Selected Paper: Design and Implementation of Secure Embedded Systems Based on Trustzone Authors: Yan-ling Xu, Wei Pan, Xin-guo Zhang Presented.

Title of Selected Paper: Design and Implementation of Secure Embedded Systems Based on Trustzone Authors: Yan-ling Xu, Wei Pan, Xin-guo Zhang Presented.
By Ronny Bull, Chaitanya Pinnamaneni, Alex Stuart.

By Ronny Bull, Chaitanya Pinnamaneni, Alex Stuart.
Bilkent University Department of Computer Engineering

Bilkent University Department of Computer Engineering
Process Description and Control

Process Description and Control
CSE331: Introduction to Networks and Security Lecture 28 Fall 2002.

CSE331: Introduction to Networks and Security Lecture 28 Fall 2002.
Page 1 Processes and Threads Chapter 2 2.1 Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.

Page 1 Processes and Threads Chapter Processes 2.2 Threads 2.3 Interprocess communication 2.4 Classical IPC problems 2.5 Scheduling.
Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra 2006/2007 3.Threads.

Operating Systems Paulo Marques Departamento de Eng. Informática Universidade de Coimbra 2006/ Threads.
Process Description and Control A process is sometimes called a task, it is a program in execution.

Process Description and Control A process is sometimes called a task, it is a program in execution.
OS Organization. OS Requirements Provide resource abstractions –Process abstraction of CPU/memory use Address space Concurrency Thread abstraction of.

OS Organization. OS Requirements Provide resource abstractions –Process abstraction of CPU/memory use Address space Concurrency Thread abstraction of.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3 Operating System Organization.

Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3 Operating System Organization.
1 RAKSHA: A FLEXIBLE ARCHITECTURE FOR SOFTWARE SECURITY Computer Systems Laboratory Stanford University Hari Kannan, Michael Dalton, Christos Kozyrakis.

1 RAKSHA: A FLEXIBLE ARCHITECTURE FOR SOFTWARE SECURITY Computer Systems Laboratory Stanford University Hari Kannan, Michael Dalton, Christos Kozyrakis.
Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3.

Slide 3-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 3.
Processes Part I Processes & Threads* *Referred to slides by Dr. Sanjeev Setia at George Mason University Chapter 3.

Processes Part I Processes & Threads* *Referred to slides by Dr. Sanjeev Setia at George Mason University Chapter 3.
Lecture Topics: 11/3 Address spaces Memory protection Creating a process –NT style –Unix style.

Lecture Topics: 11/3 Address spaces Memory protection Creating a process –NT style –Unix style.
Process Description and Control Chapter 3. Major Requirements of an OS Interleave the execution of several processes to maximize processor utilization.

Process Description and Control Chapter 3. Major Requirements of an OS Interleave the execution of several processes to maximize processor utilization.

Similar presentations

Ads by Google