security/hakurei.app
security/hakurei.app
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 4 Wiki Activity

move more under exploit protection

Browse Source
This commit is contained in:
Daniel Micay 2022-05-09 16:20:18 -04:00
parent 95eaa79691
commit e5a0f9ac52
1 changed files with 178 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

134
static/features.html
View File

@ -88,8 +88,18 @@
<li> <li>
<a href="#grapheneos">GrapheneOS</a> <a href="#grapheneos">GrapheneOS</a>
<ul> <ul>
<li><a href="#exploit-protection">Defending against exploitation of unknown <li>
vulnerabilities</a></li> <a href="#exploit-protection">Defending against exploitation of
unknown vulnerabilities</a>
<ul>
<li><a href="#attack-surface-reduction">Attack surface
reduction</a></li>
<li><a href="#exploit-mitigations">Exploit
mitigations</a></li>
<li><a href="#anti-persistence">Anti-persistence /
detection</a></li>
</ul>
</li>
<li><a href="#more-complete-patching">More complete patching</a></li> <li><a href="#more-complete-patching">More complete patching</a></li>
<li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li> <li><a href="#sandboxed-google-play">Sandboxed Google Play</a></li>
<li><a href="#disabling-secondary-user-app-installation">Disabling secondary <li><a href="#disabling-secondary-user-app-installation">Disabling secondary
@ -128,24 +138,6 @@
protect users before the vulnerability is known to the vendor and has a patch protect users before the vulnerability is known to the vendor and has a patch
developed and shipped.</p> developed and shipped.</p>
<p>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.</p>
<p>Unknown (0 day) vulnerabilities are much more widely used than most realize <p>Unknown (0 day) vulnerabilities are much more widely used than most realize
to exploit users not just in targeted attacks but in broad deployments. to exploit users not just in targeted attacks but in broad deployments.
Project Zero maintains Project Zero maintains
@ -155,6 +147,50 @@
attackers were caught exploiting users, often because the attacks are not attackers were caught exploiting users, often because the attacks are not
targeted but rather deployed on public websites, etc.</p> targeted but rather deployed on public websites, etc.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Remote code execution vulnerabilities are the most serious and allow an <p>Remote code execution vulnerabilities are the most serious and allow an
attacker to gain a foothold on device or even substantial control over it attacker to gain a foothold on device or even substantial control over it
remotely. Local code execution vulnerabilities allow breaking out of a sandbox remotely. Local code execution vulnerabilities allow breaking out of a sandbox
@ -174,6 +210,23 @@
code loading/generation/execution such as a JIT compiler bug or a plugin code loading/generation/execution such as a JIT compiler bug or a plugin
loading vulnerability.</p> loading vulnerability.</p>
<section id="attack-surface-reduction">
<h4><a href="#attack-surface-reduction">Attack surface reduction</a></h4>
<ul>
<li>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)</li>
<li>Option to disable native debugging (ptrace) to reduce local attack surface
(still enabled by default for compatibility)</li>
</ul>
</section>
<section id="exploit-mitigations">
<h4><a href="#exploit-mitigations">Exploit mitigations</a></h4>
<ul> <ul>
<li>Hardened app runtime</li> <li>Hardened app runtime</li>
<li>Stronger app sandbox</li> <li>Stronger app sandbox</li>
@ -260,6 +313,27 @@
</ul> </ul>
</section> </section>
<section id="anti-persistence">
<h4><a href="#anti-persistence">Anti-persistence / detection</a></h4>
<ul>
<li>Enhanced <a href="https://source.android.com/security/verifiedboot">verified boot</a>
with better security properties and reduced attack surface</li>
<li>Enhanced hardware-based attestation with more precise version information</li>
<li>Hardware-based security verification and monitoring: the
<a href="https://github.com/GrapheneOS/Auditor/releases">Auditor app</a> app and
<a href="https://attestation.app/">attestation service</a> 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
<a href="https://attestation.app/about">about page</a>
and <a href="https://attestation.app/tutorial">tutorial</a>.</li>
</ul>
</section>
</section>
<section id="more-complete-patching"> <section id="more-complete-patching">
<h3><a href="#more-complete-patching">More complete patching</a></h3> <h3><a href="#more-complete-patching">More complete patching</a></h3>
@ -388,17 +462,7 @@
<p>This is an incomplete list of other GrapheneOS features.</p> <p>This is an incomplete list of other GrapheneOS features.</p>
<ul> <ul>
<li>Enhanced <a href="https://source.android.com/security/verifiedboot">verified boot</a>
with better security properties and reduced attack surface</li>
<li>Enhanced hardware-based attestation with more precise version information</li>
<li>Eliminates remaining holes for apps to access hardware-based identifiers</li> <li>Eliminates remaining holes for apps to access hardware-based identifiers</li>
<li>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)</li>
<li>Option to disable native debugging (ptrace) to reduce local attack surface
(still enabled by default for compatibility)</li>
<li>Low-level improvements to the <a href="/faq#encryption">filesystem-based <li>Low-level improvements to the <a href="/faq#encryption">filesystem-based
full disk encryption</a> used on modern Android</li> full disk encryption</a> used on modern Android</li>
<li>Support creating up to 16 secondary user profiles (15 + guest) instead of <li>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 sandboxed Google Play feature. In the future, it will be used to distribute
first-party GrapheneOS builds of externally developed open source apps with first-party GrapheneOS builds of externally developed open source apps with
hardening applied.</li> hardening applied.</li>
<li>Hardware-based security verification and monitoring: the
<a href="https://github.com/GrapheneOS/Auditor/releases">Auditor app</a> app and
<a href="https://attestation.app/">attestation service</a> 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
<a href="https://attestation.app/about">about page</a>
and <a href="https://attestation.app/tutorial">tutorial</a>.</li>
<li><a href="https://github.com/GrapheneOS/PdfViewer">PDF Viewer</a>: sandboxed, <li><a href="https://github.com/GrapheneOS/PdfViewer">PDF Viewer</a>: sandboxed,
hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection, hardened PDF viewer using HiDPI rendering with pinch to zoom, text selection,
etc.</li> etc.</li>