On Thu, Apr 19, 2012 at 9:31 AM, Jarred Nicholls <[email protected]> wrote:
> Thanks for sending this out! I have a few questions inline below, and I > apologize in advance if the answers are apparent elsewhere (or will be in > future app security discussions) and I've missed them. > > On Thu, Apr 19, 2012 at 1:41 AM, Lucas Adamski <[email protected]>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 >> >> ===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 >> >> 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. >> >> ====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. >> * 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] >> > > Will application code + resources by signed and consequently validated > prior to installation? > > What are the policies of dynamic content, e.g. remote resources or CORS? > > If dynamic content is not allowed or restricted, has the idea of signed > dynamic code been discussed (to allow for unrestricted dynamic content) and > would Mozilla be interested in talking over the idea? > Thought I would clarify that by "unrestricted dynamic content" I meant simply "allowing dynamic content at all", not promoting privileges beyond the application permission set. > > >> >> ====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. >> * 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] >> > > I'm interested to see how this will look in detail, re: process sharing. > Will that be located in the Architecture wiki when solidified? > > >> * 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 >> > > Will access to the GPU for WebGL (and one day WebCL no doubt) be through > the core process, or will it be sandboxed away from the core proc within > its own limited process? > > >> # 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) >> >> === 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. >> >> 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-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
