MozillaWiki

B2G/Architecture/System Security: Difference between revisions

Page Discussion

B2G/Architecture/System Security (view source)

Revision as of 00:04, 30 May 2013

1,161 bytes removed ,  30 May 2013
Added road map, cleaned up features
(Fix links)
(Added road map, cleaned up features)
Line 19: Line 19:


Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
Current implementation is documented at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/System_security
Global tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=862082


=== Goals and scope of this document ===
=== Goals and scope of this document ===
Line 26: Line 27:
* 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]]
* Expose a road-map of the upcoming system-related security features


== Content process sand-boxing ==
=== Road Map ===
{|
{|
|Implementation Status||Priority||Proposed ETA
|Feature||Implementation Status||Priority/Importance||
|-
|-
|N/A||High||Release 2
|Seccomp|https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP)||High||
|-
|GL Proxy|N/A||High||
|-
|Supervisor process|https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon)||High||
|-
|RBAC (MAC)|N/A|Medium||
|-
|Disk Encryption|https://bugzilla.mozilla.org/show_bug.cgi?id=777917||Medium||
|-
|ASLR|https://bugzilla.mozilla.org/show_bug.cgi?id=777948 (Soon)||Medium||
|-
|Compiler hardening|https://bugzilla.mozilla.org/show_bug.cgi?id=620058||Medium||
|-
|JIT hardening|https://bugzilla.mozilla.org/show_bug.cgi?id=677272||Low||
|-
|Implement automated compliance testing of security features|N/A||Medium||
|-
|Integrity measurements|N/A|Low||
|}
|}
=== Risks ===
* Memory corruption or logical errors in the Gecko runtime leading to arbitrary code execution
* Similar faults in the operating system itself (kernel) leading to arbitrary code execution
* Information leakage, read/write access to the file system
=== Proposed implementation ===
* All access to resources <b>must</b> happen via IPDL, this means:
** No filesystem access
** Very limited access to the kernel's system calls (no ioctl(), etc.). By restriction system calls, the attack surface exposed by the kernel to web applications is greatly reduced
** No execution of native code
** Fuzzing of IPDL
*** See https://bugzilla.mozilla.org/show_bug.cgi?id=516716
Implementations of the above requirements, <u>by order of mitigation strength</u>:
==== Seccomp ====
Secure computing mode (seccomp) is a Linux kernel system call that allow us to limit which system calls (and any sub-process spawned from that point forward) can be used the process.
This is the most secure sand-box implementation.
* Seccomp mode 2:
** The no new privileges (NNP) flag ensures that the restrictions cannot be reverted, and are inherited by sub-processes
** Restrictions are therefore kept until the process (and/or sub-processes) exits
** White-listing of authorized system calls, additionally system calls can be white-listed based on the value of their arguments
* File system access, spawning of processes, access to most resources is nonexistent without escaping the sand-box
* Seccomp can be activated after the process has initialized and already accessed its normally
needed files and resources, making the process of creating a white-list much easier
* Sand-box escape scenarios:
** Kernel vulnerability triggered via one of the very few allowed system calls, this may also lead to the ability to disable seccomp
** b2g process vulnerability triggered via IPDL
* Misc & caveats:
** Requires kernel patch and kernel sources, or Linux kernel >=3.5
** Currently only available on the Nexus S AOSP sources https://bugzilla.mozilla.org/show_bug.cgi?id=790923
** WebGL requires some security sensitive system calls such as ioctl()


==== RBAC (Role Based Access Control) ====
==== RBAC (Role Based Access Control) ====
Line 78: Line 62:
* Allows for extremely flexible configurations
* Allows for extremely flexible configurations
* Restrictions are always enforced by the kernel
* Restrictions are always enforced by the kernel
* Restrictions can also be configured for other system processes and therefore sand-boxing of other processes as well (wpa_supplicant, init, etc.)
* Restrictions can also be configured for any  process and therefore sand-boxing of the non-b2g processes (wpa_supplicant, init, etc.)
* Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.


* Sand-box escape scenarios:
* Sand-box escape scenarios:
Line 87: Line 72:
* Misc & caveats:
* Misc & caveats:
** Requires a custom kernel with SELinux enabled, or other kernel patch based solution built and enabled
** Requires a custom kernel with SELinux enabled, or other kernel patch based solution built and enabled
** WebGL requires some security sensitive system calls such as ioctl()
** Security policy can be extensive and eventually require modifications to run on different devices.
 
==== rlimit ====
rlimit() is a system call that can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed.
 
* Relatively easy to implement, supported by various operating systems
** RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works
** RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)
** RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)
* Does not require kernel modifications
* Used as fall-back sand-box in other programs, such as OpenSSH
 
* Sand-box escape scenario:
** Kernel vulnerability (any)
** Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes
** Privilege escalation to root/privileged user, then disable rlimits
** User-land vulnerability via any kind of IPC
** b2g process vulnerability triggered via IPDL
 
==== chroot ====
chroot() is a well-known system call, which changes the view of the root filesystem of the process.
This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized.
 
* Can be initialized after the process has already accessed all its needed files and resources, although the process must
still be running as root when calling chroot() or must have all needed files located inside the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.
** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied
* While chroot() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.
* Does not require kernel modifications
 
* Sand-box escape scenario:
** Kernel vulnerability (any)
** User-land vulnerability via any kind of IPC
** Privilege escalation to root/privileged user, then escape via chdir('..') and chrooting back to the original root, or simply by remounting the entire device's root
** b2g process vulnerability triggered via IPDL
 
=== Proposed advanced sand-boxing improvements ===
 
* Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resource separation
** Wrapping of the IPDL messages over the TZ communication mechanism
* WebGL proxy
** Ensures the content processes do not need additional system calls such as ioctl()
** Large amount of effort needed to implement
** May reduce execution speed of WebGL code
 
== Full disk encryption (FDE) ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||Medium||Release 2
|}


== Disk encryption ==
=== Risks ===
=== Risks ===
* Device is stolen and attacker has full access to the user's data storage
* Device is stolen and attacker has full access to the user's data storage
Line 143: Line 80:
=== Proposed Implementation ===
=== Proposed Implementation ===


* Android already uses FDE in a sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html
* Android already uses disk encryption in a relatively sane manner and their approach may be re-used, see http://source.android.com/tech/encryption/android_crypto_implementation.html - Password handling should be revisited (different encryption/unlock passwords, better derivation of the password, as Android needs a very long password to resist brute force attacks).
** Android encrypts only the data partition
** Uses read-only partitions when unencrypted to ensure no data is being written
** Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
** Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
** Devices are shipped with the bootloader locked by default
** Devices are shipped with the bootloader locked by default
Line 158: Line 97:
*** Shutting the phone down ensures a better level of security assurance since the encryption is using a strong password
*** Shutting the phone down ensures a better level of security assurance since the encryption is using a strong password
*** Using a PIN for encryption generally renders the encryption useless as those can be cracked in seconds (see for example https://viaforensics.com/viaextract/viaextract-includes-android-encryption-cracking.html )
*** Using a PIN for encryption generally renders the encryption useless as those can be cracked in seconds (see for example https://viaforensics.com/viaextract/viaextract-includes-android-encryption-cracking.html )
* ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
** ChromeOS only encrypts the user's home directory.
* FDE (Full Disk Encryption)
** Requires a fast CPU or hardware acceleration
** Ensures no data is left unencrypted on the flash device


== Address Space Layout Randomization (ASLR) ==
== Address Space Layout Randomization (ASLR) ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||High||Release 2
|}


=== Risks ===
=== Risks ===
Line 182: Line 123:


== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ==
== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ==
{|
|Implementation Status||Priority||Proposed ETA
|-
|N/A||Medium||Unknown
|}


A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
A version tracking mechanism is necessary in order to decide when components of B2G need to be updated due to a security vulnerability.
Line 200: Line 136:
* The tracking software may however be provided to them, with guidance, for example
* The tracking software may however be provided to them, with guidance, for example
* Guidance on updates may also be provided instead
* Guidance on updates may also be provided instead
=== Sandbox implementations that were not selected (kept for reference) ===
==== rlimit sandbox ====
rlimit() is a system call that can be used to deny file and process creation. Like chroot(), this may be used as long as no privileged user (such as root) is running any process that is being rlimit'ed.
* Relatively easy to implement, supported by various operating systems
** RLIMIT_FSIZE = 0 requires that no file is written to (within the process) - this can already works
** RLIMIT_NOFILE = 0 requires that no new file descriptor is opened (within the process)
** RLIMIT_NPROC = 0 requires that no new thread of process is created (within the process)
* Does not require kernel modifications
* Used as fall-back sand-box in other programs, such as OpenSSH
* Sand-box escape scenario:
** Kernel vulnerability (any)
** Loading code directly in memory (instead of executing, for example, /bin/sh), then finding user-space vulnerabilities in other processes
** Privilege escalation to root/privileged user, then disable rlimits
** User-land vulnerability via any kind of IPC
** b2g process vulnerability triggered via IPDL
==== chroot ====
chroot() is a well-known system call, which changes the view of the root filesystem of the process.
This system call is not explicitly designed to secure access to the file system but may be used in this fashion as long no privileged user (such as root) is running any process within the chroot after the process has been initialized.
* Can be initialized after the process has already accessed all its needed files and resources, although the process must
still be running as root when calling chroot() or must have all needed files located inside the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.
** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied
* While chroot() restricts a process' view of the filesystem, it enforces no other restrictions. All system calls are still available to the process.
* Does not require kernel modifications
* Sand-box escape scenario:
** Kernel vulnerability (any)
** User-land vulnerability via any kind of IPC
** Privilege escalation to root/privileged user, then escape via chdir('..') and chrooting back to the original root, or simply by remounting the entire device's root
** b2g process vulnerability triggered via IPDL
Gdestuynder
Confirmed users
502

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/661611"