@nprofile1q... You can't manage these things at runtime. It's handled statically via the kernel build configuration where the functionality is disabled and SELinux policy which only permits accessing a few types of sockets. There's nothing using this so it shouldn't be enabled or accessible. There's a lot of other similar unused functionality built into the kernel and SELinux helps eliminate a lot of it as attack surface. More of this could be done but a lot is already covered.

@nprofile1q... It seems that CONFIG_CRYPTO_USER_API_AEAD has to be enabled as either built-in functionality (common for desktop/server distributions) or a module (also common) in order to exploit the vulnerability. The proposed mitigation of blacklisting the module won't work for distributions using CONFIG_CRYPTO_USER_API_AEAD=y and a bunch of desktop/server distributions have their kernels configured that way. It's also probably largely disabled for embedded and certain server distributions.

@nprofile1q... That's why we only mentioned it being the chosen attack vector for exploiting it. It's a common attack surface and attack vector for exploits which is why it was removed from Android. It's the SELinux policy disallowing access to AF_ALG outside of dumpstate which blocks exploiting it along with a standard GKI not having the userspace crypto API enabled. AOSP, stock Pixel OS and GrapheneOS don't have the relevant API enabled at all though, which we didn't realize until today.

@nprofile1q... That's why we only mentioned it being the chosen attack vector for exploiting it. It's a common attack surface and attack vector for exploits which is why it was removed from Android. It's the SELinux policy disallowing access to AF_ALG outside of dumpstate which blocks exploiting it along with a standard GKI not having the userspace crypto API enabled. It's possible some OEMs enable the userspace crypto API but can't allow AF_ALG due to neverallow rules checked by certification.

Standard Android GKI kernels also have the userspace API for Linux kernel crypto disabled including CONFIG_CRYPTO_USER_API_AEAD being unset. Many Android vendors enable a lot more functionality in the kernels but probably haven't had an actual reason to enable this functionality.

AOSP also doesn't permit setuid or setgid binaries which was the chosen attack vector for exploiting it in the proof of concept exploit. It similarly doesn't permit io_uring, user namespaces and a lot of other functionality outside of a few core processes for security reasons.

@nprofile1q... Yes, we'll post links to those here. We plan to add an extension to the forum enabling following tags to receive emails for new posts with the tag which you could do for the announcements tag.

Someone recently revived an RSS/Atom feed extension for Flarum but in general we don't want to use extensions from outside of the Friends of Flarum ecosystem since we don't want to rely on third parties writing high quality code and keeping it updated for new versions.

https://github.com/imorland/syndication

@nprofile1q... They weaken system SELinux policies for their OS changes and their vendor SELinux policies aren't as well made as Pixels. However, they'll still have these socket protections and aren't allowed to violate the standard neverallow rules which is a huge part of why Android has such extensive neverallow rules. They're partly there to stop OEM system and vendor SELinux policies from ruining the security model. Android has neverallows policies for this. Note the thread has more posts now.

We'll be moving this kind of content to our forum soon where we can write more about it and use proper formatting including headers and relevant inline images. We haven't moved to the new approach yet but we've also published this thread on our forum too:

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

The site for Copy Fail says it impacts every mainstream Linux distribution but that's not really the case. Mainstream mobile Linux is based on AOSP and doesn't have nearly as much kernel attack surface as desktop and server distributions combined with having much more hardening enabled.

https://copy.fail/

Android extended SELinux with support for ioctl command allowlists to reduce kernel attack surface. These ioctl command allowlists are used for sockets and many other core kernel devices to limit attack surface. It's also used with drivers in the vendor policies such as GPU ioctl command allowlists.