Apps/Security: Difference between revisions

Jump to navigation Jump to search
3,677 bytes removed ,  26 March 2012
No edit summary
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 =
177

edits

Navigation menu