#setuid — Public Fediverse posts

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.

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.

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.

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.

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";
};
};
```

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";
};
};
```

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";
};
};
```

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";
};
};
```

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";
};
};
```

@aral proves the #systemd devs right in their goal to rid Linux of #setuid - but with the recent LLM-assisted vulnerability hunts, I feel like we're going to see a lot more issues like these, also in completely different areas.

@aral proves the #systemd devs right in their goal to rid Linux of #setuid - but with the recent LLM-assisted vulnerability hunts, I feel like we're going to see a lot more issues like these, also in completely different areas.

@aral proves the #systemd devs right in their goal to rid Linux of #setuid - but with the recent LLM-assisted vulnerability hunts, I feel like we're going to see a lot more issues like these, also in completely different areas.

@aral proves the #systemd devs right in their goal to rid Linux of #setuid - but with the recent LLM-assisted vulnerability hunts, I feel like we're going to see a lot more issues like these, also in completely different areas.

@aral proves the #systemd devs right in their goal to rid Linux of #setuid - but with the recent LLM-assisted vulnerability hunts, I feel like we're going to see a lot more issues like these, also in completely different areas.

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

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

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

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

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

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

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

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

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

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

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

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

[Перевод] Перестаньте переживать об 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

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

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

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

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

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

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

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

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

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

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

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

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

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

“#Parallels Desktop has a couple of #setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke #bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to #local #privilege #escalation.”

https://www.thezdi.com/blog/2023/4/5/bash-privileged-mode-vulnerabilities-in-parallels-desktop-and-cdpath-handling-in-macos

“#Parallels Desktop has a couple of #setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke #bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to #local #privilege #escalation.”

https://www.thezdi.com/blog/2023/4/5/bash-privileged-mode-vulnerabilities-in-parallels-desktop-and-cdpath-handling-in-macos

“#Parallels Desktop has a couple of #setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke #bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to #local #privilege #escalation.”

https://www.thezdi.com/blog/2023/4/5/bash-privileged-mode-vulnerabilities-in-parallels-desktop-and-cdpath-handling-in-macos

“#Parallels Desktop has a couple of #setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke #bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to #local #privilege #escalation.”

https://www.thezdi.com/blog/2023/4/5/bash-privileged-mode-vulnerabilities-in-parallels-desktop-and-cdpath-handling-in-macos

“#Parallels Desktop has a couple of #setuid binaries: prl_update_helper and Parallels Service. Both binaries run with root privileges and both invoke #bash scripts to run commands with the privileges of root. For such use cases, bash specifically provides a privileged mode using the “-p” flag. Parallels Desktop prior to version 18.1.0 does not take advantage of bash privileged mode, nor does it filter untrusted environment variables. This leads to #local #privilege #escalation.”

https://www.thezdi.com/blog/2023/4/5/bash-privileged-mode-vulnerabilities-in-parallels-desktop-and-cdpath-handling-in-macos

Nueva entrada al #blog, hoy sin video, para explicar los tres permisos especiales de #linux : #setuid, #setgid y #StickyBit. Como siempre desde el #servidor @fedora

https://mainkivi.info/wordpress/?p=1431

Nueva entrada al #blog, hoy sin video, para explicar los tres permisos especiales de #linux : #setuid, #setgid y #StickyBit. Como siempre desde el #servidor @fedora

https://mainkivi.info/wordpress/?p=1431

Nueva entrada al #blog, hoy sin video, para explicar los tres permisos especiales de #linux : #setuid, #setgid y #StickyBit. Como siempre desde el #servidor @fedora

https://mainkivi.info/wordpress/?p=1431

As it turns out, the #setuid bit in #Unix was invented by Dennis Ritchie to prevent false updates to the moo game leaderboard 🤯 #Unix #history

https://minnie.tuhs.org/pipermail/tuhs/2023-February/027644.html

As it turns out, the #setuid bit in #Unix was invented by Dennis Ritchie to prevent false updates to the moo game leaderboard 🤯 #Unix #history

https://minnie.tuhs.org/pipermail/tuhs/2023-February/027644.html

As it turns out, the #setuid bit in #Unix was invented by Dennis Ritchie to prevent false updates to the moo game leaderboard 🤯 #Unix #history

https://minnie.tuhs.org/pipermail/tuhs/2023-February/027644.html

As it turns out, the #setuid bit in #Unix was invented by Dennis Ritchie to prevent false updates to the moo game leaderboard 🤯 #Unix #history

https://minnie.tuhs.org/pipermail/tuhs/2023-February/027644.html

As it turns out, the #setuid bit in #Unix was invented by Dennis Ritchie to prevent false updates to the moo game leaderboard 🤯 #Unix #history

https://minnie.tuhs.org/pipermail/tuhs/2023-February/027644.html

All right #infosec mastodon. How do I find out who is talking about a particular fresh vuln? I’m going to throw out some hashtags and see what turns up relevant conversation.

#186f495d4be1
#cve_2022_23093
#pingbof
#pr_pack

Is this a big deal because stack based #bof in a common #setuid binary, or a #shrug because #ping is capability restricted in #freebsd?

https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc