Hacker News Reader

Comment by RandomGerm4n | Hacker News Reader

That is why we should get rid of setuid binaries. GrapheneOS does not use them and was therefore not affected. On the desktop there is also a project called Secureblue based on Fedora Atomic that is moving in a similar direction and has already eliminated a large number though not all setuid binaries. As an alternative to sudo, su, and pkexec there is for example run0, which is available in distributions using systemd. Since systemd 259 there is now also the --empower parameter which like sudo elevates the privileges of the regular user. Essentially any distribution could start removing sudo and create an alias so that users don’t have to adjust immediately.

View on HN

No, it is not affected by the exploit as presented. This is a page cache write, so writing to a binary that root will run later can work too. This isn’t a reason to push an agenda that dislikes setuid binaries.

That would only work if the user had access to a binary that they wanted to run as root. Ideally this shouldn’t happen at all for most users. There is almost never a legitimate reason to run any program as root unless for example it is a service that absolutely requires it. In Fedora based distributions SELinux also prevents systemd from running any binaries or scripts that the user has access to as root. Removing setuid binaries and strictly limiting features like user namespaces through SELinux would make Linux significantly more secure. It’s absolutely ridiculous that even an outdated Android smartphone is more secure than the average Linux distribution these days.

Yeah. The whole Linux security model seems like it was designed centuries ago. Your permissions are supposed to derive from the authority granted to you at the time of your invocation, and from those with the existing authority to grant/delegate them... not from your lineage, name, possessions, or status at birth. I find it kind of funny that generations of *nix engineers appear to have perpetually struggled with this concept. For all the hate it gets, Windows got this part fundamentally right.

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.

Reply on news.ycombinator.com