'''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel)
== [[B2G]] Runtime System Security Model == Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security
=== Goals and scope of this document ===
* Extend the security measures documented on https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Runtime_security
* Limit and enforce the scope of resources that can be accessed or used by a web application
* Ensure several layers of security are being correctly used in the operating system
* Limit and contain the impact of vulnerabilities caused by security bugs, system-wide
* Web application permissions and any application related security feature is detailed in [[/Apps/Security]]
=== Content process initialization ===
{|
|Implementation Status||Priority||Proposed ETA
|-
|Done||N/A||N/A
|}
* The b2g process starts content processes, when it reaches a special type of iframe ('''<iframe mozapp>'''). This separates the web application from the rest of the content and is strongly associated to a manifest (see [[/Apps/Security]] for more information).
* The content processes are started in the container called an "out of process" container, or an OOP. It is represented by the plugin-container process and uses similar code to the plugin-container used by the desktop Firefox.
* Related bugs
** https://bugzilla.mozilla.org/show_bug.cgi?id=753107
=== Risks ===
* Leak of information when spawning the web application's content process
* Possibility to access resources/same level of privileges as the b2g process
* Bypassing the content process initialization
=== Implementation ===
* b2g calls:
** fork()
** setuid(app_0|nobody) (which is an unprivileged user)
** chrdir('/')
** execve('plugin-container')
This ensures the OOP process runs in a separate memory space (new process) and as a low rights user that cannot elevate its privileges to the level of the b2g process.
* File Descriptor handling:
** White list method - a list of permitted file descriptors (FD) is created and stored in the mFileMap object
** All unlisted FDs are forcefully closed in LaunchApp(), after fork() (where FDs are copied), and before execve()
Unlike the method which uses a blacklist (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.
== Content process sand-boxing ==
** Large amount of effort needed to implement
** May reduce execution speed of WebGL code
== Filesystem hardening ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|Done||N/A||N/A
|}
=== Risks ===
* Writing, deleting or reading files belonging to another user - this could result in an information leak or unexpected behavior, eg. privilege escalation etc.
* Execution of native code via an application vulnerability
* Vulnerabilities in setuid programs (and thus, privilege escalation)
=== Mountpoints ===
The rationale is that only areas that contain user-content may be read-write (unless the OS itself requires a new read-write area in the future), and must include nodev, nosuid, noexec options.
The filesystem mounts are restricted as follow:
{| border="1"
|+ Mounts
|-
! Mount point !! Filesystem !! Options
|-
| / || rootfs || read-only
|-
| /dev || tmpfs || read-write, nosuid, noexec, mode=0644
|-
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
|-
| /proc || proc || read-write, nosuid, nodev, noexec
|-
| /sys || sysfs || read-write, nosuid, nodev, noexec
|-
| /cache || yaffs2-or-ext4 || read-write, nosuid, nodev, noexec
|-
|| /efs || yaffs2-or-ext4 || read-only, nosuid, nodev, noexec
|-
|| /system || ext4 || read-only, nodev
|-
|| /data || ext4 || read-write, nosuid, nodev, noexec
|-
|| /mnt/sdcard || ext4-or-vfat || read-write, nosuid, nodev, noexec, uid=1000, fmask=0702, dmask=0702
|-
|| /acct || cgroup || read-write, nosuid, nodev, noexec
|-
|| /dev/cpuctl || cgroup || read-write, nosuid, nodev, noexec
|}
=== Linux DAC ===
The Linux DAC represents the well-known Linux filesystem permission model. (The traditional User/group/others - NOT Linux POSIX 1.e ACLs).
* The app_0/nobody user has no write access to any file
* The usage of setuid binaries is limited to where necessary
* Starting processes with a sane umask
Due to the flexible nature of the DAC ACLs, this section is subject to regular reviews.
== Full disk encryption (FDE) ==
** May lead to slower process startup and high performance penalties - however, recent builds of B2G pre-start a content-process, which may hide any performance penalty
== Updates == * Related bugs:** https://bugzilla.mozilla.org/show_bug.cgi?id=783638** https://bugzilla.mozilla.org/show_bug.cgi?id=715816** https://bugzilla.mozilla.org/show_bug.cgi?id=792452 === Risks ===* Compromised update package data, resulting in an untrusted update package being installed* Compromised update check** User does not see new updates are available** User is gets an out of date package as update, which effectively downgrade the software on his device* System state compromised or unknown during the installation of the update, for example, this may lead to:** Missing elements during the installation, some of which may be security fixes** Security fixes reverted by the compromised system after upgrade* Vulnerabilities in the update checking mechanism running on the device* Lack of updates or tracking for a software component with a known vulnerability === Implementation === * See the Security Review for the implementation information** https://wiki.mozilla.org/Security/Reviews/B2GUpdates === Proposed Additional Implementation: Tracking of applications versions for known security patches ===
{|
|Implementation Status||Priority||Proposed ETA
