Explicit Information Flow in the HiStar OS Nickolai Zeldovich, - PowerPoint PPT Presentation

Explicit Information Flow in the HiStar OS Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, David Mazières

Too much trusted software ● Untrustworthy code a huge problem ● Users willingly run malicious software – Malware, spyware, ... ● Even legitimate software is often vulnerable – Symantec remote vulnerability ● No sign that this problem is going away ● Can an OS make untrustworthy code secure?

Example: Virus Scanner ● Goal: private files cannot go onto the network Virus Update Scanner Process Symantec™ Private /tmp Virus Network User Files Database

Information Flow Control ● Goal: private files cannot go onto the network Virus Update Scanner Process Private /tmp Virus Network User Files Database

Buggy scanner leaks private data Virus Update Scanner Process Private /tmp Virus Network User Files Database ● Must restrict sockets to protect private data

Buggy scanner leaks private data Virus Update Scanner Process Private /tmp Virus Network User Files Database ● Must restrict scanner's ability to use IPC

Buggy scanner leaks private data Virus Update Scanner Process Private /tmp Virus Network User Files Database ● Must run scanner in chroot jail

Buggy scanner leaks private data ptrace Virus Update Scanner Process User Shell Private /tmp Virus Network User Files Database ● Must run scanner with different UID

Buggy scanner leaks private data ps setproctitle: Update 0x6e371bc2 Process Private /tmp Virus Network User Files Database ● Must restrict access to /proc, ...

Buggy scanner leaks private data disk usage Virus Update Scanner Process Private Private /tmp Virus Network User Files User Files Database ● Must restrict FS'es that virus scanner can write

Buggy scanner leaks private data Virus Update Scanner Process fcntl locking Private /tmp Virus Network User Files Database ● List goes on – is there any hope?

What's going on? ● Kernel not designed to enforce these policies P1 P2 P3 ● Retrofitting difficult Unix – Need to track potentially Kernel any memory observed or modified by a system call! – Hard to even enumerate Hardware Unix

What's going on? ● Kernel not designed to enforce these policies P1 P2 P3 ● Retrofitting difficult Unix – Need to track potentially Kernel any memory observed or modified by a system call! – Hard to even enumerate Hardware Unix

HiStar Solution ● Make all state explicit, track all communication P1 P2 P3 P1 P2 P3 Unix U1 U2 U3 Library Unix Kernel HiStar Kernel Hardware Hardware HiStar Unix

HiStar: Contributions ● Narrow kernel interface, few comm. channels – Minimal mechanism: enough for a Unix library – Strong control over information flow ● Unix support implemented as user-level library – Unix communication channels are made explicit, in terms of HiStar's mechanisms – Provides control over the gamut of Unix channels

HiStar kernel objects Container Device (Directory) (Network) Address Segment Gate Thread Space (Data) (IPC)

HiStar kernel objects Label Think of labels as Label a “tainted” bit Container Device (Directory) (Network) Address Segment Gate Thread Space (Data) (IPC) Label Label Label Label

HiStar: Unix process Process Container Address Code Data Thread Space Segment Segment

Unix File Descriptors Process A Process B File Descriptor Kernel (O_RDONLY) State

Unix File Descriptors ● Tainted process only talks to other tainted procs X Process A Process B File Descriptor Kernel (O_RDONLY) State

Unix File Descriptors X Process A Process B File Descriptor Kernel (O_RDONLY) State Seek pointer: 0xa32f ● Lots of shared state in kernel, easy to miss

HiStar File Descriptors Thread A Thread B Address Space A Address Space B File Descriptor Segment (O_RDONLY) Seek pointer: 0xa32f

HiStar File Descriptors Thread A Thread B Address Space A Address Space B X File Descriptor Segment (O_RDONLY) Seek pointer: 0xa32f ● All shared state is now explicitly labeled ● Just need segment read/write checks

Taint Tracking Strawman write(File) Tainted File Thread B Thread A

Taint Tracking Strawman ● Propagate taint when writing to file write(File) Tainted File Thread B Thread A

Taint Tracking Strawman ● Propagate taint when writing to file ● What happens when reading? read(File) Tainted File Thread B Thread A

Taint Tracking Strawman read(File) ACCESS Tainted File Thread B X Thread A DENIED

Strawman has Covert Channel X File 0 Tainted Thread B Network Thread A File 1 Secret = 1

Strawman has Covert Channel write(File 1) File 0 Tainted Thread B Network Thread A File 1 Secret = 1

Strawman has Covert Channel read(File 0) read(File 1) File 0 Tainted Thread B Network Thread A File 1 Secret = 1

Strawman has Covert Channel send email: “secret=1” File 0 Tainted Thread B Network Thread A File 1 Secret = 1

Strawman has Covert Channel ● What if we taint B when it reads File 1? read(File 0) read(File 1) File 0 Tainted X Thread B Network Thread A File 1 Secret = 1

Strawman has Covert Channel ● What if we taint B read(File 0) when it reads File 1? File 0 Thread 0 Tainted Network Thread A File 1 Thread 1 read(File 1) Secret = 1

Strawman has Covert Channel ● What if we taint B send email: when it reads File 1? “secret=1” File 0 Thread 0 Tainted Network Thread A X File 1 Thread 1 send email: Secret = 1 “secret=0”

HiStar: Immutable File Labels ● Label (taint level) is state that must be tracked ● Immutable labels solve this problem! write(...) read(...) Untainted File X Tainted Thread B Thread A X Tainted File

Who creates tainted files? ● Tainted thread can't modify untainted directory to place the new file there... Create Directory X Tainted File Untainted File Tainted Thread B Thread A Tainted File

HiStar: Untainted thread pre-creates tainted file ● Existence and label of tainted file provide no information about A Thread C Create Directory Tainted File Untainted File Tainted Thread B Thread A Tainted File

Reading a tainted file ● Existence and label of tainted file provide no information about A Thread C Directory Untainted X File Tainted Thread B Thread A X Tainted File

Reading a tainted file ● Existence and label of tainted file provide no information about A Thread C readdir(): Directory T. File's label Untainted X File Tainted Thread B Thread A X Tainted File

Reading a tainted file ● Existence and label of tainted file provide no information about A Thread C ● Neither does B's decision to taint Directory Taint self Untainted X File Tainted Thread B Thread A Tainted File

HiStar avoids file covert channels ● Immutable labels prevent covert channels that communicate through label state ● Untainted threads pre-allocate tainted files – File existence or label provides no secret information ● Threads taint themselves to read tainted files – Tainted file's label accessible via parent directory

Problems with IPC Create DB ● IPC with tainted client Client Server Thread – Taint server thread during request IPC SELECT ... Port Server Threads Time

Problems with IPC Create DB ● IPC with tainted client Client Server Thread – Taint server thread during request IPC SELECT ... Port IPC Return Server Threads Time

Problems with IPC Create DB ● IPC with tainted client Client Server Thread – Taint server thread during request IPC Port Results IPC Return Server Threads Time

Problems with IPC Create DB ● IPC with tainted client Client Server Thread – Taint server thread during request IPC – Secrecy preserved? Port IPC Return Results Server Threads Time

Problems with IPC Create DB ● IPC with tainted client Client Server Thread – Taint server thread during request IPC – Secrecy preserved? Port ● Lots of client calls – Limit server threads? Leaks information... IPC Return – Otherwise, no control Results over resources! Server Threads Time

Gates make resources explicit Create DB ● Client donates initial Client Server resources (thread) Thread SELECT ... Gate Server Threads Time

Gates make resources explicit Create DB ● Client donates initial Client Server resources (thread) Thread Gate ● Client thread runs in SELECT ... Server server address space, Code executing server code Return Gate Server Threads Time

Gates make resources explicit Create DB ● Client donates initial Client Server resources (thread) Thread Gate ● Client thread runs in Server server address space, Code executing server code Results Return Gate Server Threads Time