Disabling secondary
@@ -128,24 +138,6 @@
protect users before the vulnerability is known to the vendor and has a patch
developed and shipped.
- The vast majority of vulnerabilities are well understood classes of bugs
- and exploitation can be prevented by avoiding the bugs via languages/tooling
- or preventing exploitation with strong exploit mitigations. In many cases,
- vulnerability classes can be completely wiped out while in many others they
- can at least be made meaningfully harder to exploit. Android does a lot of
- work in this area and GrapheneOS has helped to advance this in Android and the
- Linux kernel. It takes an enormous amount of resources to develop fundamental
- fixes for these problems and there's often a high performance, memory or
- compatibility cost to deploying them. Mainstream operating systems usually
- don't prioritize security over other areas. GrapheneOS is willing to go
- further and we offer toggles for users to choose the compromises they prefer
- instead of forcing it on them. In the meantime, weaker less complete exploit
- mitigations can still provide meaningful barriers against attacks as long as
- they're developed with a clear threat model. GrapheneOS is heavily invested in
- many areas of developing these protections: developing/deploying memory safe
- languages / libraries, static/dynamic analysis tooling and many kinds of
- mitigations.
-
Unknown (0 day) vulnerabilities are much more widely used than most realize
to exploit users not just in targeted attacks but in broad deployments.
Project Zero maintains
@@ -155,6 +147,50 @@
attackers were caught exploiting users, often because the attacks are not
targeted but rather deployed on public websites, etc.
+ The first line of defense is attack surface reduction. Removing unnecessary
+ code or exposed attack surface eliminates many vulnerabilities completely.
+ GrapheneOS avoids removing any useful functionality for end users, but we can
+ still disable lots of functionality by default and require that users opt-in
+ to using it to eliminate it for most of them. An example we landed upstream in
+ Android is disallowing using the kernel's profiling support by default, since
+ it was and still is a major source of Linux kernel vulnerabilities. Profiling
+ is now only exposed to apps for developers who enable developer tools, enable
+ the Android Debug Bridge (ADB) and then use profiling tools via ADB. It's also
+ only enabled until the next boot. This isn't listed below since it's one of
+ the features we got implemented in Android itself.
+
+ The next line of defense is preventing an attacker from exploiting a
+ vulnerability, either by making it impossible, unreliable or at least
+ meaningfully harder to develop. The vast majority of vulnerabilities are well
+ understood classes of bugs and exploitation can be prevented by avoiding the
+ bugs via languages/tooling or preventing exploitation with strong exploit
+ mitigations. In many cases, vulnerability classes can be completely wiped out
+ while in many others they can at least be made meaningfully harder to exploit.
+ Android does a lot of work in this area and GrapheneOS has helped to advance
+ this in Android and the Linux kernel. It takes an enormous amount of resources
+ to develop fundamental fixes for these problems and there's often a high
+ performance, memory or compatibility cost to deploying them. Mainstream
+ operating systems usually don't prioritize security over other areas.
+ GrapheneOS is willing to go further and we offer toggles for users to choose
+ the compromises they prefer instead of forcing it on them. In the meantime,
+ weaker less complete exploit mitigations can still provide meaningful barriers
+ against attacks as long as they're developed with a clear threat model.
+ GrapheneOS is heavily invested in many areas of developing these protections:
+ developing/deploying memory safe languages / libraries, static/dynamic
+ analysis tooling and many kinds of mitigations.
+
+ The final line of defense is containment through sandboxing at various
+ levels: fine-grained sandboxes around a specific context like per site browser
+ renderers, sandboxes around a specific component like Android's media codec
+ sandbox and app / workspace sandboxes like the Android app sandbox used to
+ sandbox each app which is also the basis for user/work profiles. GrapheneOS
+ improves all of these sandboxes through fortifying the kernel and other base
+ OS components along with improving the sandboxing policies.
+
+ Preventing an attacker from persisting their control of a component or the
+ OS / firmware through verified boot and avoiding trust in persistent state
+ also helps to mitigate the damage after a compromise has occurred.
+
Remote code execution vulnerabilities are the most serious and allow an
attacker to gain a foothold on device or even substantial control over it
remotely. Local code execution vulnerabilities allow breaking out of a sandbox
@@ -174,90 +210,128 @@
code loading/generation/execution such as a JIT compiler bug or a plugin
loading vulnerability.
-
- - Hardened app runtime
- - Stronger app sandbox
- - Hardened libc
- providing defenses against the most common classes of vulnerabilities (memory
- corruption)
- -
- Our own hardened
- malloc (memory allocator) leveraging modern hardware capabilities
- to provide substantial defenses against the most common classes of
- vulnerabilities (heap memory corruption) along with reducing the lifetime
- of sensitive data in memory. The hardened_malloc
- README has extensive documentation on it. The hardened_malloc
- project is portable to other Linux-based operating systems and is being
- adopted by other security-focused operating systems like Whonix. Our
- allocator also heavily influenced the design of the next-generation
- musl malloc implementation which offers substantially better security than
- musl's previous malloc while still having minimal memory usage and code size.
-
- - Fully out-of-line metadata with protection from corruption, ruling
- out traditional allocator exploitation
- - Separate memory regions for metadata, large allocations and each
- slab allocation size class with high entropy random bases and no
- address space reuse between the different regions
- - Deterministic detection of any invalid free
- - Zero-on-free with detection of write-after-free via checking that
- memory is still zeroed before handing it out again
- - Delayed reuse of address space and memory allocations through the
- combination of deterministic and randomized quarantines to mitigate
- use-after-free vulnerabilities
- - Fine-grained randomization
- - Aggressive consistency checks
- - Memory protected guard regions around allocations larger than 16k
- with randomization of guard region sizes for 128k and above
- - Allocations smaller than 16k have guard regions around each of the
- slabs containing allocations (for example, 16 byte allocations are in
- 4096 byte slabs with 4096 byte guard regions before and after)
- - Random canaries with a leading zero are added to these smaller
- allocations to block C string overflows, absorb small overflows
- and detect linear overflows or other heap corruption when the
- canary value is checked (primarily on free)
-
-
- - Hardened compiler toolchain
- -
- Hardened kernel
-
- - Support for dynamically loaded kernel modules is disabled and
- the minimal set of modules for the device model are built into the
- kernel to substantially improve the granularity of Control Flow
- Integrity (CFI) and reduce attack surface.
- - 4-level page tables are enabled on arm64 to provide a much larger
- address space (48-bit instead of 39-bit) with significantly higher
- entropy Address Space Layout Randomization (33-bit instead of
- 24-bit).
- - Random canaries with a leading zero are added to the kernel heap
- (slub) to block C string overflows, absorb small overflows and detect
- linear overflows or other heap corruption when the canary value is
- checked (on free, copies to/from userspace, etc.).
- - Memory is wiped (zeroed) as soon as it's released in both the
- low-level kernel page allocator and higher level kernel heap allocator
- (slub). This substantially reduces the lifetime of sensitive data in
- memory, mitigates use-after-free vulnerabilities and makes most
- uninitialized data usage vulnerabilities harmless. Without our
- changes, memory that's released retains data indefinitely until the
- memory is handed out for other uses and gets partially or fully
- overwritten by new data.
- - Kernel stack allocations are zeroed to make most uninitialized
- data usage vulnerabilities harmless.
- - Assorted attack surface reduction through disabling features or
- setting up infrastructure to dynamically enable/disable them only as
- needed (perf, ptrace).
- - Assorted upstream hardening features are enabled, including many
- which we played a part in developing and landing upstream as part of
- our linux-hardened project (which we intend to revive as a more active
- project again).
-
-
- - Prevention of dynamic native code execution in-memory or via the filesystem
- for the base OS without going via the package manager, etc.
- - Filesystem access hardening
-
+
+
+
+
+ - Greatly reduced remote, local and proximity-based attack surface by
+ stripping out unnecessary code, making more features optional and disabling
+ optional features by default (NFC, Bluetooth, etc.), when the screen is
+ locked (connecting new USB peripherals, camera access) and optionally after a
+ timeout (Bluetooth, Wi-Fi)
+ - Option to disable native debugging (ptrace) to reduce local attack surface
+ (still enabled by default for compatibility)
+
+
+
+
+
+
+
+ - Hardened app runtime
+ - Stronger app sandbox
+ - Hardened libc
+ providing defenses against the most common classes of vulnerabilities (memory
+ corruption)
+ -
+ Our own hardened
+ malloc (memory allocator) leveraging modern hardware capabilities
+ to provide substantial defenses against the most common classes of
+ vulnerabilities (heap memory corruption) along with reducing the lifetime
+ of sensitive data in memory. The hardened_malloc
+ README has extensive documentation on it. The hardened_malloc
+ project is portable to other Linux-based operating systems and is being
+ adopted by other security-focused operating systems like Whonix. Our
+ allocator also heavily influenced the design of the next-generation
+ musl malloc implementation which offers substantially better security than
+ musl's previous malloc while still having minimal memory usage and code size.
+
+ - Fully out-of-line metadata with protection from corruption, ruling
+ out traditional allocator exploitation
+ - Separate memory regions for metadata, large allocations and each
+ slab allocation size class with high entropy random bases and no
+ address space reuse between the different regions
+ - Deterministic detection of any invalid free
+ - Zero-on-free with detection of write-after-free via checking that
+ memory is still zeroed before handing it out again
+ - Delayed reuse of address space and memory allocations through the
+ combination of deterministic and randomized quarantines to mitigate
+ use-after-free vulnerabilities
+ - Fine-grained randomization
+ - Aggressive consistency checks
+ - Memory protected guard regions around allocations larger than 16k
+ with randomization of guard region sizes for 128k and above
+ - Allocations smaller than 16k have guard regions around each of the
+ slabs containing allocations (for example, 16 byte allocations are in
+ 4096 byte slabs with 4096 byte guard regions before and after)
+ - Random canaries with a leading zero are added to these smaller
+ allocations to block C string overflows, absorb small overflows
+ and detect linear overflows or other heap corruption when the
+ canary value is checked (primarily on free)
+
+
+ - Hardened compiler toolchain
+ -
+ Hardened kernel
+
+ - Support for dynamically loaded kernel modules is disabled and
+ the minimal set of modules for the device model are built into the
+ kernel to substantially improve the granularity of Control Flow
+ Integrity (CFI) and reduce attack surface.
+ - 4-level page tables are enabled on arm64 to provide a much larger
+ address space (48-bit instead of 39-bit) with significantly higher
+ entropy Address Space Layout Randomization (33-bit instead of
+ 24-bit).
+ - Random canaries with a leading zero are added to the kernel heap
+ (slub) to block C string overflows, absorb small overflows and detect
+ linear overflows or other heap corruption when the canary value is
+ checked (on free, copies to/from userspace, etc.).
+ - Memory is wiped (zeroed) as soon as it's released in both the
+ low-level kernel page allocator and higher level kernel heap allocator
+ (slub). This substantially reduces the lifetime of sensitive data in
+ memory, mitigates use-after-free vulnerabilities and makes most
+ uninitialized data usage vulnerabilities harmless. Without our
+ changes, memory that's released retains data indefinitely until the
+ memory is handed out for other uses and gets partially or fully
+ overwritten by new data.
+ - Kernel stack allocations are zeroed to make most uninitialized
+ data usage vulnerabilities harmless.
+ - Assorted attack surface reduction through disabling features or
+ setting up infrastructure to dynamically enable/disable them only as
+ needed (perf, ptrace).
+ - Assorted upstream hardening features are enabled, including many
+ which we played a part in developing and landing upstream as part of
+ our linux-hardened project (which we intend to revive as a more active
+ project again).
+
+
+ - Prevention of dynamic native code execution in-memory or via the filesystem
+ for the base OS without going via the package manager, etc.
+ - Filesystem access hardening
+
+
+
+
+
+
+
+ - Enhanced verified boot
+ with better security properties and reduced attack surface
+ - Enhanced hardware-based attestation with more precise version information
+ - Hardware-based security verification and monitoring: the
+ Auditor app app and
+ attestation service provide strong
+ hardware-based verification of the authenticity and integrity of the
+ firmware/software on the device. A strong pairing-based approach is used which
+ also provides verification of the device's identity based on the hardware backed
+ key generated for each pairing. Software-based checks are layered on top with
+ trust securely chained from the hardware. For more details, see the
+ about page
+ and tutorial.
+
+
@@ -388,17 +462,7 @@
This is an incomplete list of other GrapheneOS features.
- - Enhanced verified boot
- with better security properties and reduced attack surface
- - Enhanced hardware-based attestation with more precise version information
- Eliminates remaining holes for apps to access hardware-based identifiers
- - Greatly reduced remote, local and proximity-based attack surface by
- stripping out unnecessary code, making more features optional and disabling
- optional features by default (NFC, Bluetooth, etc.), when the screen is
- locked (connecting new USB peripherals, camera access) and optionally after a
- timeout (Bluetooth, Wi-Fi)
- - Option to disable native debugging (ptrace) to reduce local attack surface
- (still enabled by default for compatibility)
- Low-level improvements to the filesystem-based
full disk encryption used on modern Android
- Support creating up to 16 secondary user profiles (15 + guest) instead of
@@ -440,16 +504,6 @@
sandboxed Google Play feature. In the future, it will be used to distribute
first-party GrapheneOS builds of externally developed open source apps with
hardening applied.
- - Hardware-based security verification and monitoring: the
- Auditor app app and
- attestation service provide strong
- hardware-based verification of the authenticity and integrity of the
- firmware/software on the device. A strong pairing-based approach is used which
- also provides verification of the device's identity based on the hardware backed
- key generated for each pairing. Software-based checks are layered on top with
- trust securely chained from the hardware. For more details, see the
- about page
- and tutorial.
- PDF Viewer: sandboxed,
hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection,
etc.