A Framework for Enforcing Information Flow Policies Bhuvan Mital Secure Systems Laboratory, Stony Brook University A Thesis Presentation in Partial Fulfillment of the Requirements for the Degree of Master of Science in Computer Science ADVISOR Prof. R.C. Sekar COMMITTEE Prof. Rob JohnsonProf. 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 writing 6/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 denotes 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!!