177
edits
Changes
m
=== [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.
no edit summary
=== Debian Keyring (Package Management) for distribution of apps ===
== 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.
= Permissions Definitions and Presentation =
