Labels and Information Flow

Similar documents
Asbestos Operating System

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

DAC vs. MAC. Most people familiar with discretionary access control (DAC)

JFlow: Practical Mostly-Static Information Flow Control

Information Flow Control

Last time. User Authentication. Security Policies and Models. Beyond passwords Biometrics

Making Information Flow Explicit in HiStar

Securing Untrustworthy Software Using Information Flow Control

Practical Mostly-Static Information Flow Control. Andrew Myers MIT Lab for Computer Science

Secure Programming Lecture 15: Information Leakage

Discretionary Vs. Mandatory

Mandatory access control and information flow control

Access Control Mechanisms

Computer Security. Access control. 5 October 2017

CS140 Operating Systems Final December 12, 2007 OPEN BOOK, OPEN NOTES

A Decentralized Model for Information Flow Control

Outline. Operating System Security CS 239 Computer Security February 23, Introduction. Server Machines Vs. General Purpose Machines

System design issues

Security Philosophy. Humans have difficulty understanding risk

Data Security and Privacy. Unix Discretionary Access Control

Advanced Systems Security: Multics

Security Models Trusted Zones SPRING 2018: GANG WANG

Operating System Security. Access control for memory Access control for files, BLP model Access control in Linux file systems (read on your own)

Introduction to Security and User Authentication

Identity-based Access Control

Operating Systems Security Access Control

Information Flow Control For Standard OS Abstractions

We ve seen: Protection: ACLs, Capabilities, and More. Access control. Principle of Least Privilege. ? Resource. What makes it hard?

Last time. Security Policies and Models. Trusted Operating System Design. Bell La-Padula and Biba Security Models Information Flow Control

CCM Lecture 12. Security Model 1: Bell-LaPadula Model

Lecture 4: Bell LaPadula

Access Control. Discretionary Access Control

CPSC 481/681 SPRING 2006 QUIZ #1 7 MAR 2006 NAME:

Access Control Lists. Don Porter CSE 506

A Haskell and Information Flow Control Approach to Safe Execution of Untrusted Web Applications

Instructions 1 Elevation of Privilege Instructions

CSE 127: Computer Security. Security Concepts. Kirill Levchenko

Lecture 15 Designing Trusted Operating Systems

Access Control Part 3 CCM 4350

Instructions 1. Elevation of Privilege Instructions. Draw a diagram of the system you want to threat model before you deal the cards.

Access Control Models

MASSACHUSETTS INSTITUTE OF TECHNOLOGY Computer Systems Engineering: Spring Quiz I Solutions

Confinement (Running Untrusted Programs)

Computer Science and Artificial Intelligence Laboratory Technical Report. MIT-CSAIL-TR August 6, 2007

Access Control (slides based Ch. 4 Gollmann)

System Enforced Transitive Read-Only Objects in KeyKOS-like Systems. This talk is about system-level assurance of an isolation property.

Language-Based Information- Flow Security

Synchronization SPL/2010 SPL/20 1

Security Architecture

Computer Security. 04r. Pre-exam 1 Concept Review. Paul Krzyzanowski. Rutgers University. Spring 2018

COS 318: Operating Systems. File Systems. Topics. Evolved Data Center Storage Hierarchy. Traditional Data Center Storage Hierarchy

A Survey of Access Control Policies. Amanda Crowell

(a) Which of these two conditions (high or low) is considered more serious? Justify your answer.

Lecture Embedded System Security Introduction to Trusted Computing

Qualifying exam: operating systems, 1/6/2014

Chapter 9: Database Security: An Introduction. Nguyen Thi Ai Thao

CS 161 Multilevel & Database Security. Military models of security

Remote Procedure Call (RPC) and Transparency

Introduction to Computer Security

Information Security Theory vs. Reality

Themes in OS research. Administrivia Last project due today. Functionality. Performance

Operating Systems. Week 13 Recitation: Exam 3 Preview Review of Exam 3, Spring Paul Krzyzanowski. Rutgers University.

CS 416: Operating Systems Design April 22, 2015

Mandatory Security and Performance of Services in Asbestos. David Patrick Ziegler

User Authentication. Modified By: Dr. Ramzi Saifan

8.3 Mandatory Flow Control Models

Complex Access Control. Steven M. Bellovin September 10,

An Overview of Security in the FreeBSD Kernel. Brought to you by. Dr. Marshall Kirk McKusick

CS2506 Quick Revision

1 HiStar OS. 2 Closing remarks. 3 Deian Stefan the industry perspective. - Software deployed on 200,000,000 systems

Storage and File Hierarchy

COS 318: Operating Systems

Outline. V Computer Systems Organization II (Honors) (Introductory Operating Systems) Language-based Protection: Solution

Architectural Support for A More Secure Operating System

Access Control. Steven M. Bellovin September 2,

6.828: OS/Language Co-design. Adam Belay

Issues of Operating Systems Security

Access control models and policies. Tuomas Aura T Information security technology

Least-Privilege Isolation: The OKWS Web Server

MULTILEVEL POLICY BASED SECURITY IN DISTRIBUTED DATABASE

CPS221 Lecture: Operating System Protection

Wedge: Splitting Applications into Reduced-Privilege Compartments

MU2a Authentication, Authorization & Accounting Questions and Answers with Explainations

CSE 565 Computer Security Fall 2018

Protection. CSE473 - Spring Professor Jaeger. CSE473 Operating Systems - Spring Professor Jaeger

Operating System Security, Continued CS 136 Computer Security Peter Reiher January 29, 2008

Java Security HotJava to Netscape and Beyond

Architecture. Steven M. Bellovin October 27,

CSE543 - Introduction to Computer and Network Security. Module: Operating System Security

OS Extensibility: SPIN and Exokernels. Robert Grimm New York University

0x1A Great Papers in Computer Security

Access Control. Steven M. Bellovin September 13,

Advanced Systems Security: Ordinary Operating Systems

Definition: An operating system is the software that manages resources

Towards Application Security on Untrusted Operating Systems

Department of Electrical Engineering and Computer Science MASSACHUSETTS INSTITUTE OF TECHNOLOGY Fall Quiz I

Hardware Acceleration for Tagging

Web Servers and Security

Faculty of Engineering Computer Engineering Department Islamic University of Gaza Network Lab # 7 Permissions

Storage and File System

Transcription:

Labels and Information Flow Robert Soulé March 21, 2007

Problem Motivation and History The military cares about information flow Everyone can read Unclassified Few can read Top Secret

Problem Motivation and History The military cares about information flow Everyone can read Unclassified Few can read Top Secret So computer scientists care about information flow Bell and LaPadula 1973, No read up, no write down Denning 1976, Lattice Model The Orange Book 1985, Trusted Computer System Evaluation

We Care Too We aren t the Dept. of Defense, but it is still important How do I know my free software doesn t steal my private data? Passwords Social Security numbers Financial Records

Three Recent Approaches JIF - A language based solution Asbestos - A kernel based solution Hi Star - Also kernel based, re-imagining Asbestos

Java Information Flow (JIF), What Is New and Different? The decentralized label model. Very different from the DoD s security model Avoids rigid constraints of traditional multilevel security systems Allows users to control their own information flow Declassification is part of the model

JIF - How Does This Work? Mutually distrusting users and programs All data is labeled When you make variable assignments, labels propagate Compiler and runtime ensures that information flow rules are not violated

Who Are These Users? JIF Principals are owners/readers/writers A principal can be a user or a group Can be authorized to act for other principals acts for allows for a delegation of powers declassifies-for reads-for These relationships from a principal-hierarchy

How Is The Data Labeled? Add label constructs to the language Privacy labels restrict read access Integrity labels restrict write access Labels and built in Java types form an extended type system Checking for type safety enforces flow rules

JIF Labels Details Privacy Labels - restrict read access A component (policy) has two parts, owner and readers Owners are the source of the data Readers are possible destinations L = {o1:r1,r2; o2:r2,r3} Integrity Labels - restrict write access Components have two parts, owner and writers Owners are the source of the data Writers are possible modifiers L = {o1:w1,w2; o2:w2,w3}

How Do Labels Propagate? Every assignment is a relabeling Relabeling is permitted according to certain rules Let s look at an example: i n t { A l i c e : Bob} x ; // A l i c e owns x, Bob can read i n t z ; z = x ; // z g e t s x s l a b e l i n t { A l i c e : Bob, Chuck} y ; x = y ; // OK: p o l i c y on x i s s t r o n g e r y = x ; // BAD: p o l i c y on y i s not as s t r o n g as x

Relabeling Details Privacy labels may be safely changed in four ways: Remove a reader - more restrictive Add a policy - more restrictive Add a reader - it is safe to add a reader r if there is already a reader r, and r acts for r. Replace an owner - it is safe to replace an owner o with a new owner o if o acts for o. Integrity labels may be safely changed in four ways: Add a writer - more restricted in subsequent use Remove a policy - restricts the number of allowed writers. Replace a writer -it is safe to replace a writer w with a writer w if w acts for w (really adding a writer). Add a policy - only if the new policy J is more restrictive than the old policy I.

Label Notation Basics Introduce a formalism so we can reason about flow The notation L 1 L 2 means L 1 is at most as restrictive as L 2. Some policy label examples: {amy : bob, carl} {amy : carl} {amy : manager} {amy : bob} Relabeling is permitted only if labels become more restrictive.

So What Is z s Label? Recall: i n t { A l i c e : Bob} x ; i n t { A l i c e : Bob, Chuck} y ; i n t z = x + y ; The new value is the least upper bound or join L 1 L 1 L 2 {amy : bob} {amy : bob, chuck} = {amy : bob; amy : bob, chuck} = {amy : bob}

How Do I System.out.println? Additional mechanism: the label {} is used for raw output channels. Data can only be written only if it has no privacy restrictions. Example: data labeled {bob : bob} cannot be written to the network because {bob : bob} {} We need a way to declassify this data so that it can be written.

Declassification for Privacy Labels A process is authorized to act on behalf of some set of principals This set is the authority of a process Data can be declassified with respect to a policy owned by a principal L 1 may be declassified to L 2 when L 1 L 2 L A where L A is a label containing exactly the policies of the form {p:} for every principal p in the current authority

Declassification for Integrity Labels L 1 may be declassified to L 2 when L 2 L I A L 1 where L I A is an integrity label in which there is a policy for every principal in the authority of the process. is the meet or greatest lower bound

Jif Language Overview Jif extends Java, supports: Mutable objects, Subclasses, Dynamic type tests, Access control, Exceptions Every expression has a labeled type a declassify operator An actsfor statement A switch label statement - if label is x, do this... Procedure call may grant authority possessed by the caller

Implicit Flows Use the program counter to control implicit information flows An expression is always at least as restrictive as the pc label Consider the code: x = 0 ; i f ( b ) { x = 1 ; } Initially the pc is {} At if(b) the pc is {b} At the assignment, enforce {b} {x}

Contributions and Limitations Contributions Decentralizes authority Focus on a usable programming model Makes information flow accessible to developers Limitations Assumes a trusted execution platform Assumes a trusted compiler. Assumes a principle hierarchy. Cannot express arbitrary, non-hierarchical relationships

Another Approach JIF offers a solution at the language level Allows for fine granularity Enforces a choice of language and compiler Perhaps this isn t the right place?

Asbestos Operating system level solution Supports server applications that keeps users isolated A web server is the running example Each application defines its own policies Every process has a send and receive label Processed communicate using messages sent to ports Kernel ensures that a process is permitted to send to another process s receive port.

Asbestos Labels Labels support decentralized compartments A program has discretionary right to declassify data in the compartment it created (similar to capabilities). Can give rights to declassify to other trusted programs Separate send and receive labels with different defaults

Asbestos Labels A label L is a function that maps handles to taint levels Handles: 61-bit opaque identifiers Levels: { *, 0, 1, 2, 3 } Syntax: { handle-1 level-1, handle-2 level-2,..., default-level } Default-level applies to all handles not explicitly mentioned For send, * is the most privileged, 1 is the default. For receive, 2 is the default.

Asbestos Label Basics Process P can send to Q if P s Q r When a message is delivered to Q, Q s send label is contaminated by P, Q s Q s P s

Discretionary Contamination (Optional Detail) A process may want to make a message more tainted C 2 This is okay, it doesn t violate flow properties The sender s new label becomes E s = P s C s Q s send label is contaminated by E s E s Q r Q s Q s E s

Declassification A process with P s (h) = has declassification privilege for h If P receives a message from process Q with Q s (h) = 3, P s (h) remains. P can forward data from Q with less taint (E s Q s ) has precedence Q s Q s (E s Q s )

Decontamination (Optional Detail) A process with privilege can distribute privilege to other processes Note that this is different from Jif, which has a fixed hierarchy of users controlling I/O channels A process can decontaminate another process by lowering their send label and raising their receive label This makes the system more permissive P can forward data from Q with less taint E s Q s D r Q s (Q s D s ) (E s Q s ), Q r Q r D r Where D s is the decontamination send label and D r is the decontamination receive label

Integrity (Optional Detail) A process may speak for a user u and therefore write to u s file This is a positive right, not a taint Asbestos must verify that a process speaks for u before permitting A verification label temporarily restricts the receiver s effective receive label E s (Q r D r ) V where V is the verification label

Event Processes Continued Processes quickly become over contaminated Event processes abstracts the notion of a single user s process state Associated with a base process Kernel state consists of: send label, receive label port receive rights, private set of memory pages

OK Web Server Demultiplexor process accepts connection, and hands it off One of several worker processes service the request OKWS isolates services in different processes Asbestos provides additional isolation within the process with event processes Supports database access through a proxy Adds a user ID column to underlying database

Limitations Label operations must be performed with every IPC (is this slow?) How are labels propagated between nodes? Limits choice of concurrency Size of the labels in the system increase with the number of sessions/users

Hi Star - What Was Wrong With Asbestos? Different goals: Unix vs. specialized web server Hi Star closes covert channels inherent to Asbestos mutable labels, IPC Lower Level kernel interface Process vs. Container+Thread+AS+Segments+Gates One third the kernel code Adds generality with user-space Unix Library System-wide support for persistent storage Asbestos uses trusted user-space file server Resources are manageable In Asbestos, had to reboot to kill a runaway process * source: OSDI 2006 Hi Star slides

Labels in Hi Star Hi Star uses Asbestos labeling system, with one clarification Recall the Asbestos Label levels: * has untainting privileges 0 cannot be written/modified by default 1 default level, no restriction 2 cannot be untainted/ exported by default 3 cannot be read/observed by default

Labels in Hi Star Continued * denoted untainting privilege, not a taint (breaks lattice) Acts in two contexts When T reads an object, treated as higher than a number When T writes an object, treated as less than a number To avoid confusion, use a new high star symbol,, Only appears in the notation, not in the labels < 1 < 2 < 3 <

Labels: New Rules T observes O requires: L O L T T modifies O requires: L T L O L T Note this affects how much T must raise label to observe object O Before said lowest possible value was LO L P Now lowest value is (L O L T ) i.e., T can keep its stars

Kernel Design Six object types Segment (Data), Threads, Containers (Directory), Address Space, Gate (IPC), Device (Network) Each object has: 61 bit object ID Label Quota, to bound storage usage 64 bytes of metadata (modification time, etc.) Flags Immutable flag makes the object read only

Single Level Store Single-level means no distinction between memory and secondary storage View memory as just a cache for disk everything persists across reboots Solves the system initialization problem without a superuser Otherwise, how would users get their *s back after a reboot?

No Superuser Root is a big security hole for information flow Can read/modify anything, violating any policy But then can you create a process you can t kill? No because allocation uses container hierarchy Any object you create is charged against a container s space quota Idea: no implicit resource allocation

Resource Exhaustion This is troublesome for both Asbestos and Hi Star The single level store and quotas help ameliorate this problem Quotas form a hierarchy under control of the system administrator This is, notably, the only inherent hierarchy in Hi Star

The wrap Program 110 line trusted program Has untainting privileges Example: untaint the virus scanner s results, and report back to the user A program cannot read tainted data unless first tainting itself If wrap is correctly implemented, program launched by wrap cannot leak information

Emulating UNIX Environment Implemented as a library in user space Information such as the exit status of the child process is made explicit by the UNIX library Hi Star file system uses segments and containers Files map to segments, directories to containers Processes are user space conventions Actually map to containers, segments, gates, threads, and address space objects File descriptors are mapped to segments

Emulating UNIX Permissions World-readable file, only writable by owner? Each user u owns two categories, ur and u w, gets * on login Set file s label to {uw 0, 1} Now default process with label {1} can t write file, but can read Group-readable file, only writable by owner? Have to introduce categories gr, g w for group, give gr, g w on login Set file label to {g r 3, u w 0, 1}

IPC Gates provide the mechanism for IPC Example: Timestamped digital signature daemon (pg. 271) Daemon knows secret signature key labeled {dr 3, d w 0, 1} Daemon creates a service gate G with {dr, d w, 1} Client running with process categories p r, p w Client allocates a new category r Client allocates a return gate Gr with label {p r, p w, 1}, clearance {r0, 2} Client jumps through gate G, starts server code with dr, d w Server code now has access to secret key, computes signature Returns to client by jumping through G r ; resets thread s labe from {d r, d w, r, 1} {p r, d w, r, 1}

Signals Implemented by sending an alert to a thread in a process Requires the permission to modify the thread s address space object Each process exposes a signal gate The gate has label {p r, p w, 1} The clearance of the gate is {u w 0, 2} Only threads that have the user s privilege can send signals to that user s process

Authentication Hi Star authenticates without any highly trusted process Users may supply their own authentication service Four separate entities coordinate to authenticate a user Login client, directory service, per-user authentication service, logging service