|
|
| Line 94: |
Line 94: |
| {{:App/Security/Distribution}} | | {{:App/Security/Distribution}} |
|
| |
|
| = Application Permissions Enforcement =
| | {{:Apps/Security/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).
| |
| | |
| == Requirements ==
| |
| | |
| == Proposals ==
| |
| === [http://www.cs.utah.edu/flux/fluke/html/flask.html 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.
| |
| | |
| {{:App/Security/Permissions}} | |
| {{:App/Security/StandardWebSecurity}}
| |
|
| |
|
| = Other = | | = Other = |