Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Introduction to Information Security 0368-3065, Spring 2015 Lecture 4: Process confinement (1/2) Eran Tromer Slides credit: Dan Boneh and John Mitchell,

Published byJack Hardy Modified over 8 years ago

Similar presentations

Presentation on theme: "1 Introduction to Information Security 0368-3065, Spring 2015 Lecture 4: Process confinement (1/2) Eran Tromer Slides credit: Dan Boneh and John Mitchell,"— Presentation transcript:

1 1 Introduction to Information Security 0368-3065, Spring 2015 Lecture 4: Process confinement (1/2) Eran Tromer Slides credit: Dan Boneh and John Mitchell, Stanford

2 2 Process confinement

3 3 Running untrusted code We often need to run buggy/unstrusted code: –Executable code from untrusted Internet sites: viewers, codecs for media players, “rich content”, “secure banking”, toolbars JavaScript, Java applets,.NET, flash, … –Old or insecure applications: ghostview, Outlook –Buggy legacy software (sendmail, bind, …) –Checking homework exercises –Honeypots –Digital right management Goal: if application misbehaves, stop it. –Kill process, alert user, write to log, report to central service…

4 4 Confinement Confinement: ensure application does not deviate from pre-approved behavior Can be implemented at many levels: –Hardware: isolated hardware (“air gap”) Difficult to manage Sufficient? –Processes in OS Isolates a process in a single operating system Separate spaces: virtual memory, view of filesystem System call interface can be controlled (“system call interposition) to –Virtual machines: isolate OSs on single hardware Application-level: –Isolating threads sharing same address space: Software Fault Isolation (SFI), e.g., Google Native Code –Interpreters for non-native code JavaScript, Java Virtual Machine,.NET CLR

5 5 Implementing confinement Key component: reference monitor –Mediates requests from applications Implements protection policy Enforces isolation and confinement –Must always be invoked Every application request must be mediated –Tamperproof Reference monitor cannot be killed … or if killed, then monitored process is killed too –Small enough to be analyzed and validated

6 6 Simple process confinement

7 7 A simple example: chroot Often used for “guest” accounts on ftp sites To confine the current process, run (as root): #chroot /home/guest root dir “/” is now “/home/guest” #su guest EUID set to “guest” Now “/home/guest” is added to file system accesses for applications in jail open(“/etc/passwd”, “r”)  open(“/home/guest/etc/passwd”, “r”)  application cannot access files outside of jail

8 8 Jailkit Problem: all utility programs (ls, ps, vi) must live inside jail jailkit project: auto builds files, libs, and dirs needed in jail environment jk_init: creates jail environment jk_check: checks jail env for security problems checks for any modified programs, checks for world writable directories, etc. jk_lsh: restricted shell to be used inside jail Restricts only filesystem access. Unaffected: Network access Inter-process communication Devices, users, … (see later)

9 9 Escaping from jails Early escapes: relative paths open( “../../etc/passwd”, “r”)  open(“/tmp/guest/../../etc/passwd”, “r”) chroot should only be executable by root otherwise jailed app can do: create dummy file “/aaa/etc/passwd” run chroot “/aaa” run su root to become root (bug in Ultrix 4.0)

10 10 Many ways to escape chroot jail as root Create device that lets you access raw disk mknod sda b 8 0 cat malicious-boot-record > sda Send signals to non chrooted process Reboot system Bind to privileged ports (<1024) fake NFS (network file system) requests from port 111 usurp incoming packets to TCP port 80 Use hard links to files outside the chroot Load kernel modules

11 11 FreeBSD jail Stronger mechanism than simple chroot To run: jail jail-path hostname IP-addr cmd calls hardened chroot (no “../../” escape) can only bind to sockets with specified IP address and authorized ports can only communicate with process inside jail root is limited, e.g. cannot load kernel modules

12 12 Problems with chroot and jail Coarse policies: All-or-nothing access to file system Inappropriate for apps like web browser Needs read access to files outside jail (e.g. for sending attachments in gmail) Do not prevent malicious apps from: Accessing network and messing with other machines Trying to crash host OS

13 13 System call interposition for process-level confinement

14 14 System call interposition Observation: to damage host system (i.e. make persistent changes) app must make system calls To delete/overwrite files: unlink, open, write To do network attacks: socket, bind, connect, send M onitor app system calls and block unauthorized calls Implementation options: Completely kernel space (e.g. GSWTK) Completely user space Capturing system calls via dynamic loader (LD_PRELOAD) Dynamic binary rewriting (program shepherding) Hybrid (e.g. Systrace)

15 15 Initial implementation (Janus) Linux ptrace: process tracing tracing process calls: ptrace (…, pid_t pid, …) and wakes up when pid makes sys call. Monitor kills application if request is disallowed OS Kernel monitored application (Outlook) monitor user space open(“/etc/passwd”, “r”)

16 16 Complications Monitor must maintain all OS state associated with app current-working-dir (CWD), UID, EUID, GID Whenever app does “cd path” monitor must also update its CWD otherwise: relative path requests interpreted incorrectly If app forks, monitor must also fork Forked monitor monitors forked app Monitor must stay alive as long as the program runs Unexpected/subtle OS features: file description passing, core dumps write to files, process-specific views (chroot, /proc/self)

17 17 Problems with ptrace ptrace is too coarse for this application Trace all system calls or none e.g. no need to trace “close” system call Monitor cannot abort sys-call without killing app Security problems: race conditions Example:symlink: me -> mydata.dat proc 1: open(“me”) monitor checks and authorizes proc 2: me -> /etc/passwd OS executes open(“me”) Classic TOCTOU bug: time-of-check / time-of-use time not atomic

18 18 Improved system call interposition: Systrace Systrace only forwards monitored sys-calls to monitor (saves context switches) Systrace resolves sym-links and replaces sys-call path arguments by full path to target When app calls execve, monitor loads new policy file Fast path in kernel for common/easy cases, ask userspace for complicated/rare cases OS Kernel monitored application (outlook) monitor user space open(“etc/passwd”, “r”) sys-call gateway systrace permit/deny policy file for app

19 19 Systrace policy Sample policy file: path allow /tmp/* path deny /etc/passwd network deny all Specifying policy for an app is quite difficult –Systrace can auto-gen policy by learning how app behaves on “good” inputs –If policy does not cover a specific sys-call, ask user … but user has no way to decide Difficulty with choosing policy for specific apps (e.g. browser) is main reason this approach is not widely used

Download ppt "1 Introduction to Information Security 0368-3065, Spring 2015 Lecture 4: Process confinement (1/2) Eran Tromer Slides credit: Dan Boneh and John Mitchell,"

Similar presentations

PlanetLab: An Overlay Testbed for Broad-Coverage Services Bavier, Bowman, Chun, Culler, Peterson, Roscoe, Wawrzoniak Presented by Jason Waddle.

PlanetLab: An Overlay Testbed for Broad-Coverage Services Bavier, Bowman, Chun, Culler, Peterson, Roscoe, Wawrzoniak Presented by Jason Waddle.
Operating System Structures

Operating System Structures
User-Mode Linux Ken C.K. Lee

User-Mode Linux Ken C.K. Lee
1 Dynamic DNS. 2 Module - Dynamic DNS ♦ Overview The domain names and IP addresses of hosts and the devices may change for many reasons. This module focuses.

1 Dynamic DNS. 2 Module - Dynamic DNS ♦ Overview The domain names and IP addresses of hosts and the devices may change for many reasons. This module focuses.
Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools Vinay Gangasani vcg110020.

Traps and Pitfalls: Practical Problems in System Call Interposition Based Security Tools Vinay Gangasani vcg
Applet Security Gunjan Vohra. What is Applet Security? One of the most important features of Java is its security model. It allows untrusted code, such.

Applet Security Gunjan Vohra. What is Applet Security? One of the most important features of Java is its security model. It allows untrusted code, such.
Chapter 6 Security Kernels.

Chapter 6 Security Kernels.
PlanetLab Operating System support* *a work in progress.

PlanetLab Operating System support* *a work in progress.
Secure web browsers, malicious hardware, and hardware support for binary translation Sam King.

Secure web browsers, malicious hardware, and hardware support for binary translation Sam King.
1 Introduction to Information Security 0368-3065, Spring 2014 Lecture 4: Process confinement Eran Tromer Slide credits: Dan Boneh and John Mitchell, Stanford.

1 Introduction to Information Security , Spring 2014 Lecture 4: Process confinement Eran Tromer Slide credits: Dan Boneh and John Mitchell, Stanford.
A SECURE JAILING SYSTEM FOR CONFINING UNTRUSTED APPLICATIONS Guido Noordende, ´Ad´am Balogh, Rutger Hofman, Frances M. T. Brazier, and Andrew S. Tanenbaum.

A SECURE JAILING SYSTEM FOR CONFINING UNTRUSTED APPLICATIONS Guido Noordende, ´Ad´am Balogh, Rutger Hofman, Frances M. T. Brazier, and Andrew S. Tanenbaum.
Security Presented by : Qing Ma. Introduction Security overview security threats password security, encryption and network security as specific.

Security Presented by : Qing Ma. Introduction Security overview security threats password security, encryption and network security as specific.
Chapter 1 Introduction. Chapter Overview Overview of Operating Systems Secure Operating Systems Basic Concepts in Information Security Design of a Secure.

Chapter 1 Introduction. Chapter Overview Overview of Operating Systems Secure Operating Systems Basic Concepts in Information Security Design of a Secure.
1 Information Security – Theory vs. Reality 0368-4474-01, Winter 2011 Lecture 5: Process confinement Eran Tromer Slides credit: Dan Boneh, Stanford course.

1 Information Security – Theory vs. Reality , Winter 2011 Lecture 5: Process confinement Eran Tromer Slides credit: Dan Boneh, Stanford course.
Running Untrusted Application Code: Sandboxing. Running untrusted code We often need to run buggy/unstrusted code: programs from untrusted Internet sites:

Running Untrusted Application Code: Sandboxing. Running untrusted code We often need to run buggy/unstrusted code: programs from untrusted Internet sites:
Towards Application Security On Untrusted OS

Towards Application Security On Untrusted OS
Defenses from Malware. Preventing exploits Fix bugs: – Audit software Automated tools: Coverity, Prefast/Prefix. – Rewrite software in a type safe languange.

Defenses from Malware. Preventing exploits Fix bugs: – Audit software Automated tools: Coverity, Prefast/Prefix. – Rewrite software in a type safe languange.
Dan Boneh Isolation The confinement principle CS155: Computer Security.

Dan Boneh Isolation The confinement principle CS155: Computer Security.
Operating Systems Concepts 1. A Computer Model An operating system has to deal with the fact that a computer is made up of a CPU, random access memory.

Operating Systems Concepts 1. A Computer Model An operating system has to deal with the fact that a computer is made up of a CPU, random access memory.
FIREWALL TECHNOLOGIES Tahani al jehani. Firewall benefits  A firewall functions as a choke point – all traffic in and out must pass through this single.

FIREWALL TECHNOLOGIES Tahani al jehani. Firewall benefits  A firewall functions as a choke point – all traffic in and out must pass through this single.

Similar presentations

Ads by Google