Distrustful Decomposition

Slides:



Advertisements
Similar presentations
November 1, 2004Introduction to Computer Security ©2004 Matt Bishop Slide #12-1 Chapter 12: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Advertisements

CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 Resource Containers: A new Facility for Resource Management in Server Systems G. Banga, P. Druschel,
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
ECE 4450:427/527 - Computer Networks Spring 2015 Dr. Nghi Tran Department of Electrical & Computer Engineering Lecture 8: Application Layer Dr. Nghi Tran.
1 Design Principles CSSE 490 Computer Security Mark Ardis, Rose-Hulman Institute April 13, 2004.
An Integrated Framework for Dependable Revivable Architectures Using Multi-core Processors Weiding Shi, Hsien-Hsin S. Lee, Laura Falk, and Mrinmoy Ghosh.
Designing Security In Web Applications Andrew Tomkowiak 10/8/2013 UW-Platteville Software Engineering Department
CS252: Systems Programming Ninghui Li Final Exam Review.
Agenda  Terminal Handling in Unix File Descriptors Opening/Assigning & Closing Sockets Types of Sockets – Internal(Local) vs. Network(Internet) Programming.
1 COMPSCI 110 Operating Systems Who - Introductions How - Policies and Administrative Details Why - Objectives and Expectations What - Our Topic: Operating.
CMSC 414 Computer (and Network) Security Lecture 14 Jonathan Katz.
Architecting Web Services Unit – II – PART - III.
4P13 Week 1 Talking Points. Kernel Organization Basic kernel facilities: timer and system-clock handling, descriptor management, and process Management.
Privilege separation in Condor Bruce Beckles University of Cambridge Computing Service.
CE Operating Systems Lecture 13 Linux/Unix interprocess communication.
Hwajung Lee.  Interprocess Communication (IPC) is at the heart of distributed computing.  Processes and Threads  Process is the execution of a program.
Lecture 16 Page 1 CS 236 Online Web Security CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
CS533 - Concepts of Operating Systems 1 The Mach System Presented by Catherine Vilhauer.
PwC New Technologies New Risks. PricewaterhouseCoopers Technology and Security Evolution Mainframe Technology –Single host –Limited Trusted users Security.
Security Architecture of qmail and Postfix Authors: Munawar Hafiz Ralph E. Johnson Prepared by Geoffrey Foote CSC 593 Secure Software Engineering Seminar.
CSI 3125, Preliminaries, page 1 SERVLET. CSI 3125, Preliminaries, page 2 SERVLET A servlet is a server-side software program, written in Java code, that.
Engineering Secure Software. Key Principles  Principle of Least privilege  Defense in Depth  Obviously No Vulnerabilities (vs. No Obvious)  i.e. Assume.
Fall 2008CS 334: Computer SecuritySlide #1 Design Principles Thanks to Matt Bishop.
June 1, 2004Computer Security: Art and Science © Matt Bishop Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Lecture9 Page 1 CS 236 Online Operating System Security, Con’t CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
R Some of these slides are from Prof Frank Lin SJSU. r Minor modifications are made. 1.
June 1, 2004© Matt Bishop [Changed by Hamid R. Shahriari] Slide #13-1 Chapter 13: Design Principles Overview Principles –Least Privilege –Fail-Safe.
Lecture 14 Page 1 CS 236 Online Secure Programming CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
6. Application Server Issues for the Project
ArcGIS for Server Security: Advanced
COMPSCI 110 Operating Systems
Modularity Most useful abstractions an OS wants to offer can’t be directly realized by hardware Modularity is one technique the OS uses to provide better.
Last Class: Introduction
Manuel Brugnoli, Elisa Heymann UAB
Protecting Memory What is there to protect in memory?
Boots Cassel Villanova University
Protecting Memory What is there to protect in memory?
Protecting Memory What is there to protect in memory?
Architecting Web Services
COMPSCI 110 Operating Systems
Chapter 2: System Structures
Architecting Web Services
Software Design and Architecture
DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S
Hierarchical Architecture
Modularity and Memory Clearly, programs must have access to memory
INTER-PROCESS COMMUNICATION
#01 Client/Server Computing
Lecture 1: Multi-tier Architecture Overview
CS703 - Advanced Operating Systems
Announcement Project 2 Due Project 3 will be out this weekend.
Operating Systems Lecture 12.
Time Gathering Systems Secure Data Collection for IBM System i Server
Software models - Software Architecture Design Patterns
Multithreaded Programming
CSE 451: Operating Systems Autumn 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 596 Allen Center 1.
Prof. Leonardo Mostarda University of Camerino
CSE 451: Operating Systems Autumn 2001 Lecture 2 Architectural Support for Operating Systems Brian Bershad 310 Sieg Hall 1.
Distrustful Decomposition
ECE 4450:427/527 - Computer Networks Spring 2017
Internet Applications & Programming
CSE 451: Operating Systems Winter 2003 Lecture 2 Architectural Support for Operating Systems Hank Levy 412 Sieg Hall 1.
CS703 – Advanced Operating Systems
Preventing Privilege Escalation
Secure Design Patterns
Design Principles Thanks to Matt Bishop 2006 CS 395: Computer Security.
Least-Privilege Isolation: The OKWS Web Server
#01 Client/Server Computing
Message Passing Systems
Presentation transcript:

Distrustful Decomposition Engineering Secure Software Distrustful Decomposition

Key Principles Principle of Least privilege Secure by design Obviously No Vulnerabilities (vs. No Obvious) Defense in Depth Assuming they get past that other defenses, how to: Protect the inner parts of the system? Limit the capabilities of the attacker? Believe our critical subsystems are secure? Note: in this lecture, “process” == “executing program” ©2015 Andrew Meneely

Permissions Challenges When programs are executed, the code has permissions (via executing user, setuid, setgid, etc.) Many programs need elevated (root) permissions to function Web servers: listen & respond on HTTP, e.g. port 80 Email servers: listen & respond on SMTP, e.g. port 25 Mobile apps: listening for text messages What permissions are truly needed, and when? Some programs have entirely separate functions that should not impact each other Browsers: one web page should not impact the others Solution: design your architecture around your permissions needs

Distrustful Decomposition Decompose the system into multiple processes with separate permissions i.e., fork() NOT threads. Threads still have shared memory. Simplify the root-level subsystems to an extreme extent Communicate via inter-process communication (see next slides) Each process distrusts the other i.e., validate the input from the other process i.e., re-check credentials and integrity mechanisms Outcomes Complex code gets sandboxed  reduce impact of an exploit More security checks get incorporated throughout the code Incorporate distrust at the architecture level

Inter-Process Communication: Simple Techniques Files Simplest for most developers, but… Files have no structure to them  complexity in inputs! Locking gets tough. It must be respected (concurrency challenges  complexity!!) Clipboard Can set and get clipboard programmatically Users don’t like you messing with this… …but you see it increasingly used in Web apps today Signals Simple messaging, not for transferring data Pre-defined by OS (Unix has ~30 of these) e.g. SIGINT, SIGTERM, SIGKILL, SIGSEGV, SIGPOLL

IPC: Advanced Techniques Named pipes a.k.a. a FIFO buffer Define a “virtual file” that one process can write to and another process reads from Supported at the OS (file system) level $ mkfifo --mode=0640 /tmp/irc_packets BTW: stdin and stdout are part of using unnamed pipes! Pro: fast!! Con: on the same system Sockets Write to a traditional networked socket via the OS network interface Sockets can be set to “loop back” to the original machine if needed Pro: scalable to multiple systems! Con: slower MANY more IPC strategies: message passing, message queues, technology-specific solutions (e.g. Java RMI), memory-mapped files Constantly evolving ecosystem due to security, reliability, simplicity, etc.

User-level operations e.g. QMail Trust & Machine boundaries Remote email server User-level operations Queue management CLI processing Error handling Configuration Virtual domains Delivery to client etc. Root-level SMTP listening VERY SMALL & SIMPLE IPC via files Root-level SMTP sending VERY SMALL & SIMPLE IPC via files, SIGPOLL Trust boundary

e.g. Sorta DD: Google Chrome Each browser tab is a separate process IPC is accomplished primarily through files via their own IPC subsystem Some IPC OS-specific mechanisms for synchronous message passing Restrict rendering processes to their individual tabs BUT! Not exactly “Distrustful” OS-level file permissions are not employed Still a lot of threads and shared memory for performance Vulnerabilities can occur where direct file access results in effective IPC

e.g. Lack of DD: Stage Fright Stage Fright Android Vulnerability of 2015 Buffer overflow in video transcoding function that produces a preview thumbnail on Android text messages Send a crafted video to a phone  arbitrary code execution No user intervention required (i.e. previews are automatically generated) BUT! Process listening to text messages requires root privs Process for producing thumbnails also ran as root Arbitrary code execution as root  cover your tracks Lesson: Separate complex, non-root functionality Avoid buffer overflows, of course.

Design & Project Implications Distrustful Decomposition is not something you want to procrastinate Easier to build upon than bolt on Introduces distrust at key points in the system Introduces necessary complexity into your system IPC abstracted into a subsystem is often the next step after DD Requires input validation and output normalization/sanitization Requires defining the communication protocols Conway’s Law may even help: separate duties among developers along process lines