MozillaWiki

B2G/Architecture/System Security: Difference between revisions

Page Discussion

B2G/Architecture/System Security (view source)

Revision as of 19:53, 16 November 2013

2,805 bytes added ,  16 November 2013
Updated for SELinux as Android supports SELinux in 4.3/4.4. Also updated how it's related to seccomp since we have seccomp now.
(Added road map, cleaned up features)
(Updated for SELinux as Android supports SELinux in 4.3/4.4. Also updated how it's related to seccomp since we have seccomp now.)
 
(7 intermediate revisions by 2 users not shown)
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
Global tracking bug https://bugzilla.mozilla.org/show_bug.cgi?id=862082


Line 26: Line 27:
* 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 are not detailed here
* Expose a road-map of the upcoming system-related security features
* Expose a road-map of the upcoming system-related security features


=== Road Map ===
=== Road Map ===
{|
{|
|Feature||Implementation Status||Priority/Importance||
||Feature||Implementation Status||Priority/Importance||
|-
|-
|Seccomp|https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP)||High||
||Seccomp||https://bugzilla.mozilla.org/show_bug.cgi?id=790923 (ASAP)||High||
|-
|-
|GL Proxy|N/A||High||
||GL Proxy||N/A||High||
|-
|-
|Supervisor process|https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon)||High||
||Supervisor process||https://bugzilla.mozilla.org/show_bug.cgi?id=845191 (Soon)||High||
|-
|-
|RBAC (MAC)|N/A|Medium||
||RBAC (MAC)||N/A|Medium||
|-
|-
|Disk Encryption|https://bugzilla.mozilla.org/show_bug.cgi?id=777917||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||
||ASLR||https://bugzilla.mozilla.org/show_bug.cgi?id=777948 (Soon)||Medium||
|-
|-
|Compiler hardening|https://bugzilla.mozilla.org/show_bug.cgi?id=620058||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||
||JIT hardening||https://bugzilla.mozilla.org/show_bug.cgi?id=677272||Low||
|-
|-
|Implement automated compliance testing of security features|N/A||Medium||
||Implement automated compliance testing of security features||N/A||Medium||
|-
|-
|Integrity measurements|N/A|Low||
||Integrity measurements||N/A|Low||
|}
|}


==== RBAC (Role Based Access Control) ====
== Features implementation details, risk analysis, discussion ==
 
Features get scoped here, before going into a tracking bug if they're selected to be worked on. Each feature should in general include some sort of risk analysis (or a threat model), and some implementation details.
 
=== Supervisor process ===
==== Risks ====
* Parent process (b2g) is compromised, gives full device access (run as root with no restriction).
 
==== Implementation ====
* Create a new, small footprint process called "Supervisor".
** Supervisor provides the following features:
*** Start system update (Any kind of - Gecko and full system updates)
*** Shutdown, Reboot system
*** Adjust process priorities (nice/renice)
*** Adjust OOM killer values (oom_adjust)
*** Possibly, load kernel modules at process startup. If not, the init process should take care of starting the necessary scripts for this task.
*** Drop privileges of spawned subprocesses
** Supervisor DOES NOT provide the following features:
*** XPCOM
*** JS runtime
*** Any other such gecko feature. This is not gecko. It MAY link to libxul and use a subset of features for IPC communication only.
* the b2g process should run as system:system instead of root:root.
* the supervisor process should run as root:root.
 
* Select an IPC mechanism. It may use libxul for this (such as IPDL).
 
See also bugs (up for discussion):
* https://bugzilla.mozilla.org/show_bug.cgi?id=845736
* https://bugzilla.mozilla.org/show_bug.cgi?id=845738
 
 
=== RBAC (Role Based Access Control) ===
==== Risks ====
* Ability from the attacker to run arbitrary code on the device once a process has been compromised
* Ability from the attacker to use a process in an unintended way and access resources that the Linux DAC cannot control access to
* In some cases, ability from the attacker to exploit the kernel through vulnerable system calls, that the processes normally wouldn't use
 
==== Implementation ====
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.
RBAC is implemented by various frameworks, including SELinux, RSBAC RC, and GrSecurity RBAC.


These frameworks are generally called Mandatory Access Control frameworks (MAC), allow setting white-lists of systems calls on any process, or group of processes, based on roles and types. Roles are assigned to the processes and users, types to the resources they access.
These frameworks are generally called Mandatory Access Control frameworks (MAC), allow setting white-lists of systems calls on any process, or group of processes, based on roles and types. Roles are assigned to the processes and users, types to the resources they access.
This allows the framework to control the access with little to no modification of the running program, unlike seccomp.
This allows the framework to control the access with little to no modification of the running program, unlike seccomp.
Both SELinux and seccomp enforce their policies by controlling system calls at the kernel level.


* 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 any  process and therefore sand-boxing of the non-b2g processes (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.)
* Restrictions can be configured for the B2G process, even thus it's running as root
* Restrictions to the content-processes make little sense when seccomp-bpf is already being used.
** Further decrease performance
** Does not lock down the content-process more strictly than seccomp
** Similar checks being performed
* Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.
* Possible to target only some processes (targeted policy), albeit a complete policy (all processes, no exception) is preferred from the security point of view.


Line 71: Line 115:


* 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, until Android 4.3 and 4.4 based Gonk, which has SELinux enabled kernels, userspace tools and an Android-only policy.
** Security policy can be extensive and eventually require modifications to run on different devices.
** Security policy can be extensive and eventually require modifications to run on different devices.
** Security policy from Android most likely needs large changes to run with B2G, and to be taken advantage of for B2G


== Disk encryption ==
=== 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


=== Proposed Implementation ===
==== Requirements ====
* Phone should be able to dial emergency numbers even when without the decryption key
 
==== Proposed Implementation ====


* 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 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).
Line 97: Line 145:
*** 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 )
* Use TRESOR to store the secret key outside RAM.
** See http://www1.informatik.uni-erlangen.de/tresor for implementation on ARM.


* ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
* ChromeOS uses a slightly different disk encryption mechanism using eCryptFS.
Line 105: Line 155:
** Ensures no data is left unencrypted on the flash device
** Ensures no data is left unencrypted on the flash device


== Address Space Layout Randomization (ASLR) ==
=== Address Space Layout Randomization (ASLR) ===


=== Risks ===
==== Risks ====
* Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory corruption vulnerabilities  
* Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory corruption vulnerabilities  


=== Proposed Implementations ===
==== Proposed Implementations ====


* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
* Upgrade Gonk to Jelly Bean's build system (newer GCC version, and complete ASLR support)
Line 122: Line 172:
** 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: Proposed Additional Implementation: Tracking of applications versions for known security patches ==
=== Updates: Proposed Additional Implementation: Tracking of applications versions for known security patches ===


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.
Gdestuynder
Confirmed users
502

edits

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