= 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).== 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=2Summary 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. {{:AppApps/Security/Permissions}}{{:App/Security/StandardWebSecurityEnforcement}}
