Application Permissions Enforcement

This section defines how permissions are to be enforced at the Operating System (kernel) level. B2G is defined as a "full Operating System" and thus requires kernel-level enforcement of permissions (A Linux Kernel based Security Model). In the Android Operating System, collaboration and cooperation is carried out between the Linux Kernel Android Security module and the userspace Android Applications: the exact same principle is required - translated into the B2G Operating System world.

Requirements

• It must not be possible for any one binary executable being compromised to result in a total systems and security failure.
  • Compromise of the main B2G executable must not result in complete control of the device (e.g. dialer, GPS, camera)
  • Compromise of an individual component (e.g. GPS) must not result in any other area (dialer, camera, main UI) being compromised
• Application Developers should be presented with easy bullet-point style permission sets that can be applied to their application.
  • These should map easily onto the enforcement within the underlying OS security model

Proposals

FLASK and SELinux for enforcing permissions

The Flask Architecture makes it possible to implement various Access Control systems. SELinux is technically an implementation of Mandatory access control based on Flask Architecture.

• Tested architecture that is used SELinux
• Follows a mandatory access control model where no permissions are granted by default
• There is no inheritance of ACLs / permissions
  • If an executable were to change / do something new, it wouldn't have its old permissions: it is given entirely new ones
  • However this means that B2G must be broken down into separate executables, communicating via files, sockets etc. (as opposed to running multiple threads and processes sharing the same easily-corruptible memory-space and file descriptors)
• "what you can do (in the new executable) depends on who you were, where you are *AND* what the current executable is."
• Adopting for use in B2G means writing an interface that mediates API / systemcalls
  • Suggestion was a JSONRPC service, because even without SELinux, one executable cannot compromise another executable merely across a socket boundary: it would be necessary for the compromised executable to attempt buffer-overruns (etc.) of the service (even if the service was on the same machine).
  • Another suggestion is to implement "NCALRPC" in the underlying XPCOM infrastructure, which would allow XPCOM-based components to seamlessly communicate entire functions across executable boundaries.
• API access would be enforced across security contexts
  • e.g. A page loaded over HTTPS would be a different context from HTTP. We may grant different access to the former context.
  • an app, which for best results would run either its javascript engine or better its own entire gecko engine as a separate executable, would be granted a security context which allowed it only the rights to execute or access other programs (such as a dialer).
  • in the case of JSONRPC service(s), the app would be granted SE/Linux permissions to access the URL which activated the dialer (this is one possible implementation)
• use of WebAPIs in the current implementation is impossible to properly protect against compromise. once a process or thread is compromised, all other threads and processes must also be considered to be compromised.

Full Discussion on NSA's SE-Linux Mailing List: http://marc.info/?l=selinux&m=133190422130989&w=2

Summary points of Discussion on NSA's SE-Linux Mailing List:

• As B2G is based on Android, it may be worthwhile investigating http://selinuxproject.org/page/SEAndroid
  • Apart from anything it will save time on developing the base permission set (to cover the main OS)
  • SE-Android is being developed by the NSA specifically to avoid the need for Android developers to get involved with the "low-level" SE-Linux permissions system.
• Stephen Smalley (NSA) has the following recommendation: See http://www.nsa.gov/research/selinux/related.shtml for some links to work done to apply Flask to various other applications like PostgreSQL, Xorg, and D-BUS.
  • Following Stephen's recommendation would allow the creation of very special permissions that are specifically relevant to B2G, for proper enforcement at the Linux Kernel level.