Application Sandboxing

naive methods

- bypass the java sandbox - libraries that you can write in compiled languages such as c that interact with the OS directly

regular expression pattern matching

- enforces the defined policies (eg. filename pattern)

challenge with Janus (file)

- if a file fails to open it should not be opened - tricky when file descriptors are duplicated because not sure whether it is valid or not - sending file descriptors over sockets - TOCTTOU (time of check to time of use) attack

inner sandbox

- isolate memory regions among apps so that even if multiple apps run in the same process space their memory is still isolated -Uses static analysis to detect security defects in code -disallow self-modifying code

Seccomp-BPF

- sandboxing framework available on linux - allows the user to attach a system call filter to a process and all of the descendants of that process

downside of seccomp

- the use of BPF -policies are compiled into bpf instructions before they are loaded into the kernel - these rules are reference by numbers so you have to check them to make sure they align - once past that you have to apply principle of least privilege properly

Janus (user level validation) steps

- this module initializes itself by setting up hooks to redirect system call requests to itself - whenever a sandboxed app makes a system call the call is redirected by the hook in the kernel to the janus kernel module - the module blocks the thread and signals the user level janus process that a system call has been requested - uses policy decision and policy engine

how seccomp bpf works

-seccomp sends packets that represent system calls to bpf interpreter. -the filter allows user to define rules that are applied to these system calls - these rules enable the inspection of each system call and its arguments and take subsequent action ( like is the call allowed to run or not )

4 types of application sandboxes

1. user level validation 2. os support 3. browser based application sandboxing 4. the java sandbox

BPD (Berkley packet filter)

a framework that was initially created for network socket filtering. - with socket filtering a user can create a filter to allow or disallow certain types of data to come through a socket

hook

a mechanism that redirects and API request somewhere else and allows it to return back for normal processing

rule based policies

define precisely what system calls and application can invoke - down to the parameters of the system calls of interest - solves the issue of users ability to run apps but restricts what those apps do on a per app basis

policies

define which system calls are permissible to the application in what way they can be used

policy file

defines the allowable files and network operations for each sandbox application

protection domain

defines what actions are safe and which are not

NaCl (chromiumum native client) browser plug in

designed to allow safe execution of untrusted native code within a browser - is a user level sandbox and works by restricting the type of code it can sandbox - code is also linked with special nacl libraries that provide access to system services

class loader

determines if an object is allowed to add classes • Ensures key parts of the runtime environment are not overwritten • Runtime data areas (stacks, bytecodes, heap) are randomly laid out

security manager

enforces protection domain • Defines the boundaries of the sandbox (file, net, native, etc. access) • Consulted before any access to a resource is allowed - called at the time an application makes a call to a specific method so it can provide run time verification - can result in a security exception being thrown

challenge with plug in architecture

how to keep the software in a plug in from doing bad things

how hooking works in terms of a sandbox

it will intercept a system call, inspect its parameters, and decide whether to allow the system call to take place or return an error

hooking (system call interposition)

process of intercepting an app's system calls and performing addition operations - if we don't have the ability to recompile and app or force it to use other libraries we rely on this to construct a sandbox

sandbox

provide a controlled and restricted environment for code execution - program can run with minimal risk of causing widespread damage to the system - can be used to observe how software behaves / identify presence of malware

policy engine

receives system call notifications and decides whether to allow or disallow the system call - if so it is directed back to the operating system

biggest challenge with Janus (system calls)

the user level monitor must mirror the state of the operating system - it needs to keep track of the network operations but also the right order (fork, fork) - janus does not have the knowledge if a system call should pass or not so if its in the wrong order it wont know - if this happens then may enable attack vectors like sending data on an unconnected block

outer sandbox

uses system call interposition to restrict the capabilities of apps at the system call level - done at user level via libraries and not hooking

bytecode verifier

verifies java bytecode before it is executed • Disallow pointer arithmetic • Automatic garbage collection • Array bounds checking • Null reference checking

how applications interact

via system calls to the operating system

plug-in architecture

where modules could be loaded into the browser to extend its capabilities (ex: adobe flash, java)