Changes

Jump to: navigation, search

Apps/Security

235 bytes added, 17:56, 20 March 2012
FLASK and SELinux for enforcing 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 you're executingthe 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.
177
edits

Navigation menu