On Thu, Apr 19, 2012 at 12:59 PM, Jim Straus <[email protected]> wrote:
> Thanks for pulling this together. Some comments inline below. > > On Apr 19, 2012, at 1:41 AM, Lucas Adamski wrote: > > > Much anticipated, here is a high-level overview of the B2G runtime > security model. We are calling this the "runtime" B2G security model to > avoid confusion with the underlying Linux OS security model, though > obviously the two are closely interrelated so this document touches on the > latter as well. > > > > Explicit thanks to Guillaume Destuynder, Chris Jones and Paul Theriault > for putting this together. They deserve all the credit (though I, as the > messenger, will take any blame). > > > > ==B2G Runtime Security Model== > > > > [note: this is an overview of the B2G runtime security model; the B2G > application security model discussion is happening in parallel] > > > > ===Introduction=== > > The goals of the B2G runtime security model are to: > > * enforce the permissions granted to Web Apps > > * protect the underlying operating system from attack from malicious > content > > * protect the B2G core and content processes from attack from malicious > content > > > ===Enforcing permissions=== > > The Web App Permissions model (in progress) describes how users grant > permissions to applications (either directly, or through a trusted third > party). Ensuring that these permissions are enforced correctly is critical > to ensuring the security of user data and the integrity of the application > platform B2G provides. With this in mind, web app permissions are enforced > at multiple layers within B2G to reduce the risk of the permission model > being compromised. > > > > The controls outlined below are based on the architecture documented at > https://wiki.mozilla.org/B2G/Architecture. Key points to note are: > > * The B2G core process is high-privileged and has access to most > hardware devices > > * Web Apps run in a low-privileged B2G content process and only > communicate to the B2G core process via IPDL > > * Each Web API has associated IPDL interface > > Can we have the various Web APIs run in their own, somewhat less > privileged, processes and not the B2G core process? This could help > isolate API compromises. > > > Other key concepts are: > > * B2G Permissions Database: B2G contains a central permissions database > that stores the permissions granted to all web apps. Permissions are added > at installation time, and can only be modified by the permissions manager > app. > > Haven't we been discussing permissions also being potentially added by a > permission dialog with a "remember setting" option? Also, the permissions > manager application can adjust permissions beyond just installation time. > Or are you thinking that at installation time the set of possible > permissions is enumerated and then the value (grant, deny) is adjusted in a > variety of ways (installation, at point of use, permissions manager)? > > Or just refer to the permissions discussions and eventual design. > > > > ====Web App Layer==== > > *Web Apps are loaded inside a special type of iframe (currently <iframe > mozapp>) that separates the web apps from other content, and is strongly > associated with a Web App manifest, which describes the Web App. > > * Each web app has an associated set of permissions. When the web app > attempts to call certain sensitive APIs, these permissions are checked, and > will only succeed if the application is granted the associated permission. > > See above > > > * Each app is hosted on a separate domain. It may only access the > resources associated with its domain (indexedDB, cookie store, offline > storage etc.). The only exception is if the app has permissions to access > APIs that access common resources such as contacts, photo gallery, media > store, usb devices etc. [Not really true, and TBD to boot] > > > > ====Content Processes==== > > * All Web Apps run in a low-rights content process (B2G content process) > spawned via fork() by the b2g process (B2G Core process). These content > processes are sandboxed to have no direct access to file system or OS. B2G > content processes can only communicate through IPC mechanism (IPDL) back to > the B2G core process, which will perform actions on behalf of content. > > We'll need to be careful of what is currently known to the Core process > when the fork is done to keep the content processes from having access to > various parts of the core process. Might it be better to exec the content > processes? > Same thing came to mind. On posix Chromium fork()'s and obtains the child pid, then in the child builds up a (crazy long) list of args to pass state & other info, e.g. IPC channel ids, and then does an execvp() for the renderer process. > > > * Web Apps are loaded in separate content processes to allow for further > attack surface reduction. Ideally apps are separated one per process, or if > this isn’t possible due to resource constraints, trusted Web Apps with > access to sensitive are separated from less trusted WebApps. [will that be > true for M3?] [I think so, but I dont know for 100% sure] > > * B2G content processes will have access to a record of the privileges > associated with the applications running in them. B2G content processes > will enforce this at a web api level, and as such will never send IPDL > messages for APIs which the Web Apps in their process don’t have access to, > unless they have been compromised in some way. In this case the B2G core > process will enforce the permissions (see next point). > > * In this way, each B2G content process is associated with a set of > permissions – exactly the union of all permissions from each app running > inside it. The B2G core process validates the IPDL messages from a B2G > content process, and if a message is detected which requests access to an > API that is outside the set of permissions, the B2G core process denies > this request. This scenario should never happen under normal operation, as > the B2G content process should be enforcing permissions on its apps, so as > a precaution the offending B2G content process will be killed and > re-spawned. > > > > ===Protection of the underlying OS=== > > In B2G applications are Web Apps - there are no binary ("native") > applications installed by the user, and all system access is mediated > through WebAPIs. There is no direct filesystem access. As such the key > threats to the underlying operating system are: > > > > # A memory corruption vulnerability in gecko leading to arbitrary code > execution > > # Compromise of the update mechanism used > > # Hijacking another web application (XSS, or memory corruption) > > # IPDL vulnerability > > > > The approach to mitigation of code execution threat is: > > # Hardening gecko against attack (the same approach as for Firefox) > > # Run web content in lower-rights child processes to reduce the impact > of process compromise (the B2G content process) > > # Harden the underlying OS to make post-exploitation more difficult > > # Use the hardening features of the compiler > > > > ====Process model and separation (sandboxing, etc.)==== > > As previously specified the B2G process model is based on: > > # One B2G core process (parent) which has access to all hardware, > devices etc > > # One or more B2G content processes (child), which only needs enough > system access access to communicate with parent process. > > > > In case of a vulnerability in B2G content processes, the OS limits the > impact by denying system level resource access to the low-privilege content > processes. Compromising the B2G core process is equivalent to complete > system compromise. > > Compromising a B2G content process can still lead to the access of > application's permissions running in the same B2G content process. > > > > We are investigating seccomp mode 2 (require kernel patch for < 3.5) in > orer to allow: > > recv, send, exit (+any other whitelisted system call necessary for > WebGL, such as ioctl) for B2G content processes. > > Any other system call is denied by the kernel for B2G content processes. > > > > The effectiveness of using low-rights B2G content process as a > mitigation technique is also dependant on the control of communication > between childs (B2G content processes) and the parent process (B2G core > process). > > IPDL is used as an IPC mechanism via UNIXSOCK and SHM (shared memory). > Access requests are done via IPDL and authorized given a certain > application ID. The core risk in IPDL is in the serialization and > deserialization of data types. IPDL has built-in types which are well-known > and tested, and are used where possible. Where deserialization must be done > by hand, security review is required. Furthermore, upon encountering any > deserialization errors, the child process is killed. > > > > === Future (M3+) === > > # The goal is to have a finer level of separation between various > software components, in particular the B2G core process's components > > ## WebGL Graphics pipeline segregation and consequently tighter > sanboxing of the B2G content processes > > # Investigate running the B2G core process and B2G content processes in > separate ARM TrustZones > > # Investigate Role Based Access Control (enforced at the kernel level): > RSBAC/SELinux/Etc (see also a similar project: > http://selinuxproject.org/page/SEAndroid ,mainly the policy at > http://selinuxproject.org/~seandroid/git/selinux/sepolicy/) > > > > ====OS Hardening==== > > Mozilla will provide a reference implementation and recommendations for > OS security controls. > > # Filesystem privileges enforced by Linux's ACLs (pending review) > > ## The B2G core process runs as root and has CAP_DAC_READ_SEARCH (and > others), thus ACLs are not a security measure for this process > > ## The B2G content processes run as a regular user and have a very > restricted access > > # /system mounted read-only > > # Compilation of all the software with SSP/PIE and FORTIFY_SOURCE. > > # Review of system daemons setup (wpa_supplicant, gpsd, etc) > > In conjunction with partners since many are device specific and not > supplied by Mozilla. It would be good to document the set of system > daemons required, have independent specifications of the system daemons > (beyond "what Android say"), and possibly provide a reference set of system > daemons. > > > > === Future (M3+) === > > # Investigate CoreBoot secure boot support (ala ChromeOS) > http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=9aea04aa892903009e487ada7f7b911691e68630 > > # See also: > http://www.chromium.org/chromium-os/chromiumos-design-docs/system-hardening > > > > ==== OS Update ==== > > > > OS updates includes everything except gecko, which has its own update > process (see below). > > OS updates are issued when a user-impacting bug or a security bug is > found, or when a required for a B2G major upgrade. > > > > OS Updates can be done in 2 different ways. > > > > 1) Via a firmware image, through USB. The fast boot booloader is > required. Note that this can be used to install any other OS as well and > has no restrictions. > > This method is also used when method 2) fails (power issue, hardware > failure, etc.) and "brick" the device. > > Can the fastbootloader require signatures even for USB updates? > > > > 2) OTA ("on the air"). While the prefered method, this mechanism has not > yet been defined from a functional point of view. It will be similar to > Android's OTA mechanism. > > > > However: > > # Strong crypto signature verification is required before installing > those packages > > # The complete update must be downloaded in a specific and secure > location before the update process starts > > # The system must be in a secure state when the update process starts > (no Web Apps running) > > # The keys must be stored in a secure location on the device > > > > ==== B2G Update ==== > > B2G updates itself using the same mechanism as Firefox on the desktop. > > > > # The updates are fetched over SSL > > # SSL certificates's issuer names are pinned in B2G > > # Updates are signed in the update file (MAR format, see also: > https://wiki.mozilla.org/Software_Update:MAR) > > > > See https://bugzilla.mozilla.org/show_bug.cgi?id=715816 for > implementation (in progress) > > > > _______________________________________________ > > dev-webapps mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-webapps > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
