AOSP and GrapheneOS have a small allowlist of socket types in the SELinux policies preventing using AF_ALG outside of the dumpstate service used to gather system wide debugging information for bug report zips. It's not available as attack surface on AOSP-based operating systems in practice.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
AOSP not permitting setuid/setgid binaries is certainly useful attack surface reduction but isn't how it blocks exploiting this vulnerability. It blocks it via SELinux policy having allowlists for socket types which don't permit AF_ALG to be used outside of the dumpstate service.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.
Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.
Lockdown Mode is focused on reducing the attack surface from Safari including the WebView and Apple services including iMessage/FaceTime. It does nearly nothing to protect against non-browser/non-messaging attack vectors in the OS or other apps. It's up to app developers to implement similar restricted modes and also baseline exploit protections. App developers need to explicitly opt-in to using the standard exploit protections used in many parts of the OS and Apple discourages doing it:
iPhones with Lockdown Mode enabled have definitely been exploited which is confirmed by leaked documents and statements from commercial exploit vendors. Lockdown Mode primarily reduces attack surface in Safari and from Apple services. It does very little to protect against other attack vectors such as messaging apps or physical data extraction.
You're thinking of Apple saying they haven't detected a case of a device with Lockdown Mode exploited in the wild themselves. Extremely few devices use Lockdown Mode and Apple has very little insight into successful exploits so there isn't much opportunity for them to detect it in the first place. Lockdown Mode bundles everything together and has very inconvenient changes many people won't accept. That greatly reduces usage even by people fully aware of it who want a lot of what it provides. For example, there's
Apple has said they haven't seen a case of a device with Lockdown Mode being exploited which is extremely misleading. Apple doesn't have that much visibility into devices being exploited and would mostly seen failed attempts. All of the Lockdown Mode functionality being bundled together contributes to it barely being used. There's no opt-out system for most of it beyond disabling it as a whole. Only a subset of the Safari restrictions can be partially disabled per-app and per-site which doesn't fully restore web compatibility. It's more that hardly anyone is using it and that Apple doesn't have much insight into apps and the OS being exploited successfully in the first place. Lockdown Mode is definitely useful but people should read about what it actually does and compare that to how devices get exploited. Apple's memory corruption exploit protections aren't tied to Lockdown Mode.
The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.
The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.
This is great to hear, I've been wanting a flip phone for a while. GrapheneOS on a Moto Razr would actually be incredible. Thank you for all of your hard work and being active in this thread. I'm looking forward to getting my hands on a Motorola with GrapheneOS :)
It has always been a hardware requirement to be able to unlock the device, install GrapheneOS and lock the device again. Verified boot has been a requirement since it was introduced for Pixels and the is main benefit of locking the device. There are additional security features enabled by verified boot. The overall hardware requirements are listed at https://grapheneos.org/faq#future-devices.
SailfishOS doesn't use the security features which are being worked on and doesn't keep up with kernel, driver and firmware updates. It doesn't use secure elements, verified boot or hardware memory tagging so it doesn't need the work being done on those things. They don't have similar requirements for hardware and have little use for what's being worked on for these devices.
The portions of SailfishOS specific to it are largely closed source including the user interface and application layer. It isn't possible to fork the overall operating system. It has much worse privacy and drastically worse security than the Android Open Source Project even without taking the GrapheneOS improvements into account. It's in an entirely different space and this has no connection to it.
True, for the most parts, and that's because they are resource constrained and Jolla is on the verge of bankruptcy. But all those features are not important to me. I care more about privacy (surveillance capitalism) than "security" (from state actors or malicious hackers). And seek diversity in software system by not supporting the duopoly of Android and ios, both from American BigTech. Sailfish OS ( https://sailfishos.org/ ) meets those requirement better. If Graphene OS becomes popular, it is likely to be surreptitiously gobbled up by one of the BigTech, just like Microsoft's investment in Cyanogenmod ... moreover, with Google slowly making Android more and more proprietary, I personally don't see a good future for GrapheneOS, and bet on Sailfish OS outlasting it.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
reply