MozillaWiki

B2G/Architecture/System Security: Difference between revisions

Page Discussion

B2G/Architecture/System Security (view source)

Revision as of 01:21, 2 November 2012

834 bytes added ,  2 November 2012
Typos, etc. Fixes comes from :imelven. Thanks!
mNo edit summary
(Typos, etc. Fixes comes from :imelven. Thanks!)
Line 6: Line 6:
'''''Content process''''' : This is a sub-process spawned by the b2g process, and which communicates with the b2g process. It represents a web application. This is a low-privileged process (i.e., run as regular user and has a very limited access and view of/to the operating system).
'''''Content process''''' : This is a sub-process spawned by the b2g process, and which communicates with the b2g process. It represents a web application. This is a low-privileged process (i.e., run as regular user and has a very limited access and view of/to the operating system).


'''''IPDL''''': Intercommunication Protocol Definition Language, see [[/IPDL]].
'''''IPDL''''': Intercommunication Protocol Definition Language, see [[https://wiki.mozilla.org/IPDL]].


'''''AOSP''''': Android Open Source Project.
'''''AOSP''''': Android Open Source Project.
Line 12: Line 12:
'''''Proposed <*>''''': This means the section has <b>NOT</b> yet been implemented in b2g and is being discussed. In that case, a status, priority and a proposed ETA is also included.
'''''Proposed <*>''''': This means the section has <b>NOT</b> yet been implemented in b2g and is being discussed. In that case, a status, priority and a proposed ETA is also included.


'''''system call''''': An interface to talk between the user-space(processes) and the kernel. There is no other way for a user-space to talk to the kernel.
'''''system call''''': An interface to talk between the user-space(processes) and the kernel. There is no other way for a user-space process to talk to the kernel.


'''''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]] Runtime Security Model ==
=== Goals and scope of this document ===
* 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
Line 37: Line 39:
* Leak of information when spawning the web application's content process
* Leak of information when spawning the web application's content process
* Possibility to access resources/same level of privileges as the b2g process
* Possibility to access resources/same level of privileges as the b2g process
* Bypassing the initialization
* Bypassing the content process initialization


=== Implementation ===
=== Implementation ===
Line 46: Line 48:
** execve('plugin-container')
** execve('plugin-container')


This ensures the OOP process runs in a separate memory space (new process) and as a low right user, that cannot elevate it's privileges to the level of the b2g process.
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:
* File Descriptor handling:
** White list method
** White list method - a list of permitted file descriptors (FD) is created and stored in the mFileMap object
** 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()
** All unlisted FDs are forcefully closed in LaunchApp(), after fork() (where FDs are copied), and before execve()


Unlike the blacklist method (Close-on-exec flag: CLOEXEC), this ensures not FD is left open, and is therefore more reliable.
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 70: Line 71:
** No filesystem access
** No filesystem access
** Very limited access to the kernel's system calls (no ioctl(), etc.)
** Very limited access to the kernel's system calls (no ioctl(), etc.)
** No execution of native ocode
** No execution of native code
** Fuzzing of IPDL [DONE]
** Fuzzing of IPDL
*** See https://bugzilla.mozilla.org/show_bug.cgi?id=516716


Implementations of the above requirements, <u>by order of preference</u>:
Implementations of the above requirements, <u>by order of mitigation strength</u>:


==== Seccomp ====
==== Seccomp ====
Line 82: Line 84:
** The no new privileges (NNP) flag ensures that the restrictions cannot be reverted, and are inherited by sub-processes
** 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
** Restrictions are therefore kept until the process (and/or sub-processes) exits
** White-listing of authorized system calls, may include system call arguments
** 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
* File system access, spawning of processes, access to most resources is nonexistent without escaping the sand-box
* Can be initialized once the process has established access to all the needed files & resources
* 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:
* Sand-box escape scenarios:
** Kernel vulnerability triggered via one of the very few allowed system calls
** 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
** b2g process vulnerability triggered via IPDL


Line 98: Line 101:
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), and allow to set white-lists of system calls to 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 allow the framework to control the access with little or no modifications made to the running programs, unlike seccomp.
This allows the framework to control the access with little to no modification of the running program, unlike seccomp.


* 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 thus sand-boxing of other processes (wpa_supplicant, init, etc.)
* Restrictions can also be configured for other system processes and therefore sand-boxing of other processes as well (wpa_supplicant, init, etc.)


* Sand-box escape scenarios:
* Sand-box escape scenarios:
** The escape scenarios always depend on the security rules
** The security provided by the framework depends entirely on the rules/policy applied to the system
** Generally, any kernel vulnerability triggered via one of the allowed systems calls, and in some cases, the ability to disable the framework
** Any kernel vulnerability triggered via an allowed system call - this may also lead to the ability to disable the MAC framework
** b2g process vulnerability triggered via IPDL
** b2g process vulnerability triggered via IPDL


* Misc & caveats:
* Misc & caveats:
** Require a custom kernel with SELinux enabled, or other solutions patched in 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()
** WebGL requires some security sensitive system calls such as ioctl()


==== chroot ====
==== chroot ====
chroot() is a well-known system call, which changes the view of the root filesystem of the process. This system call is not made for security file system access, but may be used in that fashion, as long no privileged user (such as root) runs within the 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 once the process has established access to all the needed files & resources, if the program is modified to do so, as the program has to still be running as root when chroot() is called (or to have all files available in the chroot directory). See https://bugzilla.mozilla.org/show_bug.cgi?id=776648.
* 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
** Linux namespaces can be used in combination with the chroot in order to reduce the amount of code changes or files copied
* While chroot() provides a different view of the filesystem, it does not provide any other separation. All system calls are still available to the process.
* 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
* Does not require kernel modifications


Line 130: Line 135:
=== Proposed advanced sand-boxing improvements ===
=== Proposed advanced sand-boxing improvements ===


* Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resources separation
* Use of ARM TrustZones (TZ), which implements hardware virtualization and strong resource separation
** Wrapping of the IPDL messages over the TZ communication mechanism
** Wrapping of the IPDL messages over the TZ communication mechanism
* WebGL proxy
* WebGL proxy
** Ensures the content processes do not need additional system calls such as ioctl()
** Ensures the content processes do not need additional system calls such as ioctl()
** Large task
** Large amount of effort needed to implement
** May reduce execution speed of WebGL code
** May reduce execution speed of WebGL code


== Filesystem hardening ==
== Filesystem hardening ==
Line 146: Line 150:


=== Risks ===
=== Risks ===
* Writing, deleting or reading files of another users, resulting in information leak, or unexpected behavior (privilege escalation, etc.)
* 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
* Execution of native code via an application vulnerability
* Vulnerabilities in setuid programs (and thus, privilege escalation)
* Vulnerabilities in setuid programs (and thus, privilege escalation)


=== Mountpoints ===
=== Mountpoints ===
The rationale is that only areas that contain user-content may be read-write (unless the OS itself require a new read-write area in the future), and must include nodev, nosuid, noexec options.
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:
The filesystem mounts are restricted as follow:


Line 161: Line 165:
| / || rootfs || read-only
| / || rootfs || read-only
|-  
|-  
| /dev || tmpfs || read-write, nosuid, noexec, mode=0755
| /dev || tmpfs || read-write, nosuid, noexec, mode=0644
|-  
|-  
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
| /dev/pts || ptsfs || read-write, nosuid, noexec, mode=600
Line 185: Line 189:


=== Linux DAC's ACLs ===
=== Linux DAC's ACLs ===
The Linux DAC's ACLS represents the well-known Linux filesystem permission model. (User, group, others owners and read, write, execute modes).  
The Linux DAC's ACLS represents the well-known Linux filesystem permission model. (User, group, others owners and read, write, execute modes).  


Line 202: Line 205:


=== Risks ===
=== Risks ===
* User device is copied in order to steal his sensitive data
* Device is stolen and attacker has full access to the user's data storage


=== Proposed Implementation ===
=== Proposed Implementation ===


* Android already uses FDE in a sane manner and may be copied, see http://source.android.com/tech/encryption/android_crypto_implementation.html
* 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
** Locking/Unlocking the bootloader wipes the device (all blocks to 0) and restores it to factory settings(fastboot)
** Locking/Unlocking the bootloader wipes the device and restores it to factory settings, this is enforced by fastboot
** Devices are installed with the bootloader locked by default
** Devices are shipped with the bootloader locked by default
* A user interface must be present to set the encryption password
* A user interface must be present to set the encryption password
* Allow a weaker screen lock password:
* Potential UX issues and proposed solutions
** Problem solved
** Allow a weaker screen lock password:
*** Unlocking the phone screen is done several times a day, sometimes several times within a few minutes, thus users very rarely use a strong phone unlocking mechanism (generally, a 4 to 8 number PIN code)
*** Unlocking the phone screen is done several times a day, sometimes several times within a few minutes, thus users rarely use a secure mechanism for their screen lock
*** User is not tempted to use a weak PIN to decrypt the phone, since decryption only occurs during phone startup (key is kept in memory afterwards)
*** Users are not tempted to use a weak PIN/password for FDE, since they are only asked for the FDE password at phone startup, not
every time they want to unlock their phone and use it
** Additional risks
** Additional risks
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
*** Weaker screen unlock mechanism (such as a PIN), can lead to access to the encrypted data
Line 229: Line 233:


=== Risks ===
=== Risks ===
* Vulnerabilities in the application's code lead to easy to guess addresses in the code, and thus easy exploitation of the vulnerability
* Loading libraries and application code at predictable or fixed addresses leads to easy exploitation of memory
corruption vulnerabilities


=== Proposed Implementations ===
=== Proposed Implementations ===
Line 235: Line 240:
* 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)
** Faster, newer GCC, smaller performance impact from ASLR
** Faster, newer GCC, smaller performance impact from ASLR
** Full ASLR, the complete process memory image's addresses are randomized
** This provides full ASLR, no fixed or predictable addresses are used
** Require upgrading the build system
** Requires upgrading the build system


* Enable ASLR support, PIE, and linker ASLR in the current build system
* Enable ASLR support, PIE, and linker ASLR in the current build system
** Require patching of various components
** Requires patching of various components
*** Failure to do so would result in a half functioning ASLR, which is not much better than no ASLR support
*** Failure to do would result in only partial ASLR, which is no better than no ASLR
** May lead to slower process start and high performance penalties
** May lead to slower process startup and high performance penalties


== Updates ==
== Updates ==
Line 252: Line 257:
=== Risks ===
=== Risks ===
* Compromised update package data, resulting in an untrusted update package being installed
* Compromised update package data, resulting in an untrusted update package being installed
* Compromised update check, user does not see new updates are available
* Compromised update check
* System state compromised or unknown during the installation of the update
** User does not see new updates are available
* Vulnerabilities in the update checking mechanism
** 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
* Lack of updates or tracking for a software component with a known vulnerability


Gdestuynder
Confirmed users
502

edits

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