Folks complaining (validly) about why we're still using archaic stuff like #SETUID for privilege escalation.

Meanwhile:

SELinux: "Am I a joke to you?"

Like, the security stuff to make linux tighter than factory lug nut is there, and has been there for literal decades.

The question is whether we value it more than our convenience.

I can't remember if it was SELinux or AppArmor, or one of the other Linux security overhaul mechanisms, but one of them used to have a publicly-accessible demonstration server where you would ssh in as root and try to hack around. I remember trying it out, and sure enough, you basically couldn't do a single thing on the box, even logged in directly as root.

While #NixOS should not be affected by #CopyFail as it uses recent kernels, here are additional fixes you can apply:

Disabling setuid does not mitigate it, but reduces the attack surfaces overall significantly.

Instead of #sudo, #su, #pkexec and other #setuid binaries you can use #run0 or a dedicated root account.

I have disabled setuid for a bunch of binaries I don't need, they still work when ran as root, with run0 or #sudo-rs.

```nix
boot.blacklistedKernelModules = [
"algif_aead"
];

security.sudo.enable = false;

security.wrappers = {
su.enable = false;
pkexec.enable = false;

# example setuid binary
chsh = {
source = "${pkgs.shadow}/bin/chsh";
setuid = lib.mkForce false;
owner = "root";
group = "root";
};
};
```

[Перевод] Перестаньте переживать об allowPrivilegeEscalation

Многие инженеры теряются в нюансах настройки allowPrivilegeEscalation в Kubernetes. Автор статьи простым языком объясняет, зачем нужен этот флаг, как он работает и почему его наличие или отсутствие не критично для большинства сценариев. Если хотите понять, как устроена безопасность контейнеров, — эта статья для вас.

https://habr.com/ru/companies/flant/articles/923432/

#allowPrivilegeEscalation #поды #kubernetes #security_contexts #контексты_безопасности #setuid #setreuid #привилегированный_контейнер #безопасность_контейнеров

wait3() System Call as a Side Channel in #Setuid Programs: nvidia-modprobe case study (CVE-2024-0149)

https://security.opensuse.org/2025/03/26/nvidia-modprobe.html

One Bug Wasn't Enough: Escalating Twice Through SAP's Setuid Landscape

https://www.anvilsecure.com/blog/one-bug-wasnt-enough-escalating-twice-through-saps-setuid-landscape.html

#HackerNews #OneBugWasntEnough #SAP #Security #Setuid #Vulnerability #Cybersecurity #Exploit #BugBounty

I could also mount the encrypted partitions on the #HardDrive and to recreate the symbolic link which I’d deleted. Luckily this allowed my original system to start #Booting again. However, something was still wrong with sudo but looking it up, there was ample help online about what was wrong: the #program has to be #setuid 0 and so once I was able to do that I recovered the system. Phew.

#GNU #Linux #ShaggyDogStory

Linux Kernel: TOCTOU in Exec System | …I am sure that there was a vulnerability of this exact kind in Unix circa 1988 +/- 4yrs

I’m pretty sure there was a direct one on the inode permissions, and possibly a second one involving symlinks. Every bug has its day again and again and again.

There is a Time-of-Check / Time-of-Use issue in the Linux kernel in the exec system calls. The executability permissions are checked at a different time than the set-user-ID bit is applied. This could lead to privilege escalation.

https://github.com/google/security-research/security/advisories/GHSA-c45w-xwww-rfgg

#CVE202443882 #security #setuid #unix