[Feature Request] Adopt Hardening Efforts from GrapheneOS

[sempervictus]

Is your feature request related to a problem? Please describe. In the conventional mobile device space GrapheneOS defines and implements the most robust hardening model available to the public. Primary focus areas from which this project may benefit:

1. kCFI+LTO linux-hardened kernels
2. hardened_malloc memory allocator defeating various classes of bugs (or raising exploitation complexity to "infeasible")
3. SELinux policy and implementation improvements in the Linux and Android layers

Other likely less applicable but possibly valuable functions include attestation, bootloader protection, A/B verified updates, etc

Proposed approach

1. Formal definition of platform threat model: components, vectors and mechanics of access, capabilities, and attacker value based on Most Probable Course of Action (MPCOA) and Most Dangerous Course of Action (MDCOA) to bound ranges of concern for each vector identified.
2. Mapping defensive capabilities outlined in the GrapheneOS documentation to the elements of the model defined with killchain impacts (increase in complexity, addition of requirements for attacker progression, outright mitigation, etc).
3. Implementing identified viable defensive mechanisms (and liaison with developers) to effect standoff and improve user safety with process and mechanisms for automated maintenance downstream of the relevant projects' ongoing R&D.

Additional context Reason for proposing this is "basic opsec" - vanilla systems are easier to compromise, infect, persist within, and utilize to the attacker's needs than those which implement strict isolation backed by systems and component hardening (check my GH history, speaking from "some experience" in offsec-land). Having a fully-privileged mobile foothold which follows a person with an array of radio equipment at one's disposal is a non-trivial capability for everything from identity theft to corporate and conventional espionage. Its common practice for high security environments to require that phones be left outside but watches are still often regarded as benign/simple things which underestimates the threat profile of these things (wrist computers with an array of comms gear and sensors).

[beroset]

Aspects of this kind of hardening may be possible, but we have a fundamental problem, which is that some of the essential device drivers are proprietary blobs created by the manufacturer and largely completely undocumented (at least for the public). We use libhybris to enable these drivers, but this means that the supported watches all have relatively old kernels which can't be updated until and unless replacement device drivers can be created and perhaps upstreamed.

See for example: https://github.com/AsteroidOS/asteroid/issues/162

[sempervictus]

Given the age of these kernels, i wonder if any of the old grsec patches (https://github.com/linux-scraping/grsecurity-patches/tree/master/grsec-3.10) might apply to and build in these kernel trees. Should provide a bit more standoff than retroactively patching semi-connected watches.

That said, there have been a lot of bluetooth and wireless stack exploits in the years since 3.x were maintained. How safe is it to implement IO paths if the driver stacks atop which they reside are vulnerable to their contents (blueooth, wireless, etc)?

[sempervictus]

I did a quick bit of cherry-picking for the Fossil kernel off the GrapheneOS 4.14 branch - https://github.com/fossil-engineering/kernel-msm-fossil-cw/pull/5. Haven't tried building it yet but this should help add some runtime entropy and allocator hardening to complicate (or break) various killchains which would otherwise succeed more easily relying on upstream weaknesses in mm or predictability of stack contents