A Framework for Enforcing Information Flow Policies

Bhuvan MitalSecure Systems Laboratory,

Stony Brook University

A Thesis Presentation in Partial Fulfillment of the

Requirements for the Degree ofMaster of Science

inComputer Science

ADVISORProf. R.C. Sekar

COMMITTEEProf. Rob Johnson Prof. Scott Stoller

Outline of the presentation

Motivation for a new framework

Framework Design

Framework Implementation

Evaluation

Related Work

Conclusion

Future Work

2/24

Need for Information-Flow Techniques Reactive approaches are ineffective

Code Encryption / Obfuscation evade Signature-based Scanning and Behavior Monitoring

Policy-based confinement is difficult Policies are difficult to develop

Vulnerable to multi-step attacks

Mediation of writes alone is not the solution Trojan Attack on Windows Vista Start Menu

3/24

Need for Information-Flow Techniques

The solution lies in mediating both reads and writes

Mediating read-downs and write-ups for Integrity Preservation.

Mediating read-ups and write-downs for Confidentiality Preservation.

Information Flow Techniques can provide a solution

4/24

PPI's Information-Flow Approach Premise of the PPI (Practical Proactive Integrity

Preservation) approach

System Integrity is preserved as long as integrity-critical Objects (files, pipes, sockets, etc.) are not written by low-integrity Subjects (processes)

PPI thwarts malware and maintains flexibility

5/24

Challenge to Information Flow: Delayed Failures

Editor opens file1 for writing6/24

Editor reads file2 and gets downgraded

Delayed Failures

7/24

Downgraded editor causes loss in usability

Delayed Failures

Solution : Make the application trusted

Is Trusting all applications, a solution?

8/24

Motivation for a new Framework Promote early failures to enhance usability

e.g. Deny opening a file for reading when a high integrity file is open in the editor.

Limit Trust Only a few selected applications are Trusted.

Scalable and Flexible Design Extensible Framework for enforcing policies for preserving Integrity

as well as Confidentiality

Building a working model for a modern operating system A scalable framework that adapts to a contemporary OS design

9/24

Basics about our framework Built using the Linux Security Module (LSM) infrastructure

Entities in our framework

Objects : Files, pipes, sockets, IPC channels

Subjects : Processes

Handles : Indirection between objects and subjects

Labels : Abstract data-types for denoting object/subject integrity or confidentiality.

current label: Basis for forward information flow min label: Basis for constraint propagation

Prevents undesirable downgrading

10/24

Tuple < x,y> denotes <current_label, current_min_label >

Design of our framework Promotes Early Failures by propagating Constraints

11/24

Design of our framework (contd.)

Trusting Applications

Some subjects can sanitize their inputs and must be trusted. e.g. ssh server trusted for all inputs on port 22

Input Validation: Integrity Model Our Framework makes such subjects invulnerable

Limits Trust by defining input invulnerability level

12/24

13/24

PPI Object Types : Some Examples

Symbolic Links

Have a context association

Attacker may create low integrity symlinks to a high integrity file

Solution : Virtually Downgrade Process

Named Pipes

Just like named files in the filesystem

Un-named Pipes

Special handling done in the framework for PPI Handle creation on Un-named pipes

14/24

Framework Implementation

Goals

Identifying the hooks for enforcement Fitting the framework in the LSM infrastructure

15/24

Framework Implementation

Goals

Identifying the hooks for enforcement Fitting the framework in the LSM infrastructure

16/24

Framework Implementation Analysis of code flow . e.g. Task Exec

17/24

Framework Implementation Analysis of code flow . e.g. Socket Accept

18/24

Framework Implementation

Key Challenges in mapping our framework to LSM

Hook selection Overcoming the limitations of LSM

Example: No hook for mediating all sys_close events Problem of closing handles on objects by

forked processes => stale handles in the system Solution: Validate handles before using them

19/24

Framework Evaluation Test Setup

VMWare virtual machine with 2.6 GHz processor, 512MB RAM and 10 GB of free HD space

Implementation for Sockets / IPCs not complete

Full-System testing not done

Evaluation of Correctness

More than 50 use cases developed for testing

Our framework passes all tests

Evaluation of Performance

Testing with Core-Utils 6.10 standard test-suite passes all tests

Average overhead in CPU time : 30%20/24

Framework Evaluation Performance Graph (Limited testing for Core-Utils 6.10)

21/24

Biba Integrity Model [ Biba '77]

Strict Model, enforces No read downs and No write ups

LOMAC [Fraser 2000]

Integrity Preservation for Linux by enforcing Low Watermark policy

Windows Vista

Only No write up policy, subject to indirect attacks

Back to the future [ACSAC 2006]

Only No read down policy, impact system availability

SELinux [Loscocco 2001]

Primary focus on servers, not safe to use for untrusted applications.

Related Work

22/24

Conclusion Our Framework Preserves Usability

Promote Early Failures by propagation constraint

Limits Trust Invulnerability of applications can be restricted

Scalable and Flexible Design Extensible Framework for enforcing policies for preserving

Integrity as well as Confidentiality

Implementation of Label as an abstract data type

Our framework fits well into a contemporary OS Current implementation uses the LSM framework

23/24

Implementation to be completed for Sockets and IPC objects

Full system evaluation and benchmarking

Reducing the CPU time overhead by optimizations

Enforcing Confidentiality policies through the framework

Mapping the framework to other operating systems

Future Work

24/24

Your Questions Please !!!

25/25

Thank you!!