Rule-based Sandboxes and Application-oriented Access Controls: Computer Security Lectures 2014/15 S2
Channel: Z. Cliffe Schreuders
Date: 2015-06-13

This video is part of the computer/information/cyber security and ethical hacking lecture series; by Z. Cliffe Schreuders at Leeds Beckett University. Laboratory work sheets, slides, and other open educational resources are available at http://z.cliffe.schreuders.org. 

The slides themselves are creative commons licensed CC-BY-SA, and images used are licensed as individually attributed.

Topics covered in this lecture include:

Rule-based sandboxes can control what each application is authorised to do
The program is launched into a sandbox, which can enforce exactly which files are assessable
System call interposition schemes filter system calls
Systrace, Janus, Etrace, TRON
MAPbox, confines programs based on behaviour classes
Disadvantages: system calls can be complex
Rule-based system-wide access controls are similar, except they don't require applications to be launched into a sandbox
Often mandatory controls
When one application starts another a policy transition may occur, changing the policy that is applied
Coarse grained rights
Examples: Android (more later), Bitfrost
Linux capabilities: break up root permissions, so that other privileges can be dropped. 
Disadvantages: not all types of permissions can be represented that way (e.g., files)
Normally on Unix, there are two types of users:
privileged (uid=0)
unprivileged (uid!=0)
Root (0) can do anything
Bypasses all kernel permission checks
Capabilities divide these privileges
Capabilities can be granted to, or removed from individual processes
Programs can be programmed to drop caps (delete, or temporarily disable)
Program files can have capabilities attached
Capability bounding sets
Remove the ability for kernel modules to be loaded after the system starts, (can help prevent root kits)
Domain and type enforcement (DTE)
SELinux
Created by the NSA
Mandatory access controls for Linux
Combines a number of models, including DTE (application-oriented), RBAC (user-oriented)
Basically, every file has a security label that defines the type, and transition rules state what 'domain' a process is in, and what types the domain can access
Another approach taken by some schemes, is to simply specify a list of all the resources each application is authorised to access
AppArmor, TOMOYO
Side note: my research, functionality-based application confinement
Integrity levels
Windows Vista+
Defines ”a new access control entry (ACE) type to represent an integrity level”
Restricts programs that are less trustworthy
Designed to work without users involvement
Other integrity-based schemes include the seminal Biba access control model
Windows 8 AppContainer
In Windows 8, “Metro” apps are sandboxed using AppContainer
Each Metro app is restricted to its AppData directory
Any other access (for example, to documents / music / video) requires specific permission or user interaction
“AppContainer” is a new integrity level, and each application has its own SID
Apps declare what capabilities they will use, ahead of time
A manifest declares capabilities required
Mobile security: Android
Android architecture
Applications are confined to the permissions that developers request in a manifest file
Built in permissions
Apps can also define their own permissions
Applications communicate and provide services to one another (need to be careful)
The Linux kernel enforces the rules
Use of UID
Code is self-signed, and only apps sharing the same publisher can share the same UID
UIDs are assigned at install, some “built-in” apps have their UIDs hardcoded
Applications are installed by users
There are App stores from Google / Amazon
Google do static analysis, and can remove apps from devices
Trojan horses exist
SMS Trojans
Third party security extensions
Disk encryption
SE Android: adds MAC
Encrypted calls and SMS
Anti-malware
Permissions removal from installed apps
Mobile security: iOS
Apple's iOS runs on iPhones and iPads
All apps run in a sandbox, that grants more or less the same permissions to every app
Grants apps access to the address book and browsing history
Some special actions require user-interaction to approve
Apple maintains a walled garden approach to security
Some users jailbrake their devices
Malware has targeted rooted iOS devices
Egele et al. “Detecting privacy leaks in iOS applications” 2012
Malware has been found in the AppStore
Possibly less malware targeted at iOS than Android
Possible deterrents
Web app security
Software is often developed using Web technology, such as HTML and CSS
Web browsers attempt to isolate pages from each other
Google's Chrome web browser (Chromium is the name of the open source version) has a number of security mechanisms
Each tab runs in a separate process
Extensions/plug-ins run in a sandbox (with limited access to the OS)
Native code allows websites to run x86 code within an isolated sandbox
HTML5 sandbox attribute restricts an iframe (a page within a page)
Allows mash-ups in a controlled manner