Rule-based Sandboxes and Application-oriented Access Controls: Computer Security Lectures 2014/15 S2

• Report rights infringement
• published: 13 Jun 2015
• views: 649

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