|
|
| Line 16: |
Line 16: |
| '''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel) | | '''''DAC, MAC''''': Discretionary Access Control (up to the user) and Mandatory Access Control (enforced by the kernel) |
|
| |
|
| == [[B2G]] Runtime Security Model == | | == [[B2G]] 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 === | | === 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 | | * 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 | | * 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 | | * 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]] | | * 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 == | | == Content process sand-boxing == |
| Line 159: |
Line 130: |
| ** Large amount of effort needed to implement | | ** Large amount of effort needed to implement |
| ** May reduce execution speed of WebGL code | | ** 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) == | | == Full disk encryption (FDE) == |
| Line 265: |
Line 181: |
| ** 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 | | ** 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 == | | == Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches == |
| | |
| * 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 | | |Implementation Status||Priority||Proposed ETA |