5 ms·

Most of them by very far rely on sudo. I've got a system without sudo. The only way to execute something as root on my system is to log in, using a U2F securi

Most of them by very far rely on sudo. I've got a system without sudo. The only way to execute something as root on my system is to log in, using a U2F security key, from a second system (typically a small laptop sitting next to my workstation). That second system is connected to my workstation on a dedicated LAN only used by these two machines. Firewalls on both (for example my workstation only allow SSH in from that one LAN and only from the IP of my laptop on that LAN etc.). The laptop has no Internet access, WiFi disabled (modules prevented from loading, firewall preventing network access, etc.). The laptop's sole purpose is to run command as root on the workstation: it's its sole purpose. The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation. I think no sudo even installed on the machine beats the "never allow root SSH" mantra but YMMV. (to set up the system I install the system offline, from a Debian installation medium whose checksum and signature I've verified, do my thing as root on the workstation, set up the login using U2F from the laptop, then I "lock myself out" from login as root directly at the workstation by entering a password so long I'll never enter it, something like "neverenterthisrootpasswordanymoreusethelaptopu2fkeyinstead#$bey8rUtIopTY6"*. A bit of pain to enter twice but then I'm good to go)

simonblack 3y ago
I've got a system without sudo Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password. The downside is that I allow "root SSH", contrarily to every single best practice out there. Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".
tiffanyh 3y ago
OpenBSD sudo replacement, “doas”, plus them reworking the need for root to run services - address above. https://man.openbsd.org/doas https://man.openbsd.org/doas
GuB-42 3y ago
These bypasses are typically not for when are the only user and also the administrator. Sudo here is not really for securing your machine: as others have said, if an attacker gets to your personal account, it is game other. It is mostly a tool for you to avoid fucking up your system by mistake. These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.
voxadam 3y ago
Do you also disallow su on your system or is it just sudo that's been banished? Edit: I'm curious because if you still allow su on the system there seems to be little to no reason to set PermitRootLogin in sshd_config regardless of auth mechanism (password, cert, token, etc.).
- fuzztester 3y ago
  Yes, good question. Because su was there in Unix before sudo, IIRC. And sudo means "su do", meaning do (something) as su, which in turn meant "super user" or "substitute user" according to Wikipedia, since it can also be used to login as other users than root , e.g.: su - tom https://en.m.wikipedia.org/wiki/Su_(Unix) https://en.m.wikipedia.org/wiki/Su_(Unix)
alufers 3y ago
Out of curiosity: What sensitive things does the root account protect on your workstation? On my desktop (and probably 99% of people's desktops here) getting access to the user account is game over. The password manager? Runs as my user - one ptrace and the key can be extracted. Cookies for all my online services? Sitting right there in the home directory. The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install. And don't get me wrong, I don't like this situation - I tried running some high-risk programs (browser, Libre Office) under flatpak to achieve at least some separation - but it breaks too many things.
- drbawb 3y ago
  On my system the root account is primarily for upgrades, but also storage administration! ZFS snapshots protects me against silly mistakes like strange permutations of `rm -rf ~/` in day to day operations. Not having root all the time protects me against `zfs destroy -r nagato/data/home/drbawb` which will nuke my home folder, 144 frequent snapshots (15 minute intervals per 36 hours), 14 daily snapshots, 4 weekly snapshots, and 3 monthly snapshots. That would suck. A lot. (I have a file called "RIP", where a drive image used to be mounted, because I got a little too over-zealous with the recursive option on some ZFS commands on a file that had `copies=1`. _RAID is not a backup, snapshots are not a backup, etc._) This also means that theoretically ransomware (running without root) could encrypt my home directory, but apart from doubling the number of blocks used on disk it would have no real impact on my data. (If someone writes a virus that can encrypt the blocks inside a ZFS partition, without mangling ZFS data structures beyond repair, then I'll be more impressed than angry. Not even the ZFS devs can rewrite block pointers on a running filesystem.[1]) That being said ZFS has an awesome feature called delegation which lets you run a subset of commands without root permissions. I use it sparingly, mostly to allow unprivileged backups. (Each host gets a login on my backup server, and can only create/destroy datasets that are children of a host-specific dataset. So `nagato` can `zfs destroy -r backup/hosts/nagato` but not `zfs destroy -r backup/hosts` or `zfs destroy -r backup/hosts/someone-else`.) [1]: https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s
- mormegil 3y ago
  Yeah, that's the classic https://xkcd.com/1200/ https://xkcd.com/1200/ I thought about using Qubes OS on my new computer but it seemed like a lot of work and tweaking and still having to live with the limitations so I abandoned the idea.
mike_hock 3y ago
They don't rely on sudo. The sudo tag merely indicates that if sudo is configured to allow "your" (the pwned) user account to run them, they can also be used for privileged operations that might not have been intended by whoever configured sudo that way. "Never allow root SSH" together with the strong implication that it should be used in conjunction with sudo, has always had a very weak rationale behind it, since as soon as you actually ever make use of sudo to elevate your privileges, for an attacker there is almost no meaningful distinction between your user account and plain root. Looking at the historic reality, the weak rationale more than evaporates completely. Due to various CVEs, sudo has, in retrospect, been a trojan horse for most of its existence that allowed privilege escalation from any user account regardless of its configuration. The period for which sudo has had these vulnerabilities overlaps rather well with the period for which it has been championed as "best practice" along with the tenuous justifications based on security by obscurity and to avoid "user mistakes." In that light, your setup seems perfectly sane to me, however I don't believe sudo is relevant as a backdoor anymore in 2023 and the focus has most likely shifted to something else.
tureu92 3y ago
I think at this point you are solving a wrong problem. Getting root access through X zero days exploits is not so hard. And if you uninstall `sudo` and `su`, and only login as root on dedicated TTY, you have very similar security. I use Qubes OS for stuff like this. Way better security, no need to juggle tokens, dedicated lans and so on. Only real problem is no graphical acceleration in browser (Google Earth...)
- chaxor 3y ago
  Doesn't Qubes require like 32GB of RAM just to run? I would love to use it, but most of the use cases I would like to try it for are much more in the realm of SBCs with 2-8GB of RAM for running services locally. It would be great to have that extra security, but the cost is really really high.
  - tureu92 3y ago
    systemd-nspawn...
  - colejohnson66 3y ago
    > Doesn't Qubes require like 32GB of RAM just to run? 32 GB minimum, but 16 GB recommended.[0] I think that's backwards, so I'd say it's actually 16, not 32 required. But yes, that's more than a typical SBC will have. The Pi 4, for example, has a maximum configuration of 8 GB, but some have modded it to have 16 GB.[1] [0]: https://www.qubes-os.org/doc/system-requirements/ https://www.qubes-os.org/doc/system-requirements/ [1]: https://www.techradar.com/news/a-raspberry-pi-4-with-16gb-its-been-done-but-theres-a-big-catch https://www.techradar.com/news/a-raspberry-pi-4-with-16gb-it...
    - bazodedo 3y ago
      I was curios about that 16GB pi. (I want to have one myself :) Unfortunately, it looks like soldering the 16gb ram chip onto the pi did not increase the usable memory due to other hardware limitations. [1] https://forums.raspberrypi.com/viewtopic.php?t=350514 https://forums.raspberrypi.com/viewtopic.php?t=350514
gsich 3y ago
>The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation. Allowing root login is fine. The best practice is not to allow passwords for root login.
- TacticalCoder 3y ago
  > The best practice is not to allow passwords for root login. My sshd is configured to not allow passwords logins at all: it's U2F/Yubikey only.
  - gsich 3y ago
    I somewhat like smartcards more. Takes use of the slot, not wasting rare USB ports on notebooks. I don't why there are so few USB ports, but that's another discussion.
- johnklos 3y ago
  The even better than "best" practice is to not allow passwords for any login. Keys really aren't that hard.
chasil 3y ago
Did you remove all of these? $ cd /usr/bin $ for x in ./*; do [ -u "$x" ] && printf "$x\\n"; done ./at ./atq ./atrm ./chage ./chfn ./chsh ./crontab ./fusermount ./fusermount3 ./gpasswd ./mount ./newgrp ./passwd ./pkexec ./sg ./staprun ./su ./sudo ./sudoedit ./umount ./vmware-user ./vmware-user-suid-wrapper $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) I notice that chsh is not on the list of the parent article.
- TacticalCoder 3y ago
  > Did you remove all of these? So if you can't protect versus all the threats, you may as well not do anything?
  - chasil 3y ago
    Perhaps a more reasoned approach would be to rewrite them in rust, or some other hardened language for greater security.
- sigotirandolas 3y ago
  What really matters is not whether you have sudo (or su, pkexec, etc.) installed, but rather that you never, ever escalate privileges from a less trustworthy user to a more privileged one, since at a conceptual level this combines the low trustworthiness with the high privileged-ness. Instead, when you want to elevate privileges, you should do so by using a mechanism that takes the control of the machine away from less trustworthy user - such as a Secure Attention Key or similar mechanism.
  - chasil 3y ago
    But all of these programs escalate privileges from less trustworthy to more. $ ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 33424 Apr 1 2022 /usr/bin/passwd The "s" above indicates that the program is allowed to call the setuid() family of functions to alter the real, effective, and/or saved user id. You would not be able to change your password without the functionality.
jonas-w 3y ago
None of them rely on sudo. https://gtfobins.github.io/gtfobins/sudo/ https://gtfobins.github.io/gtfobins/sudo/ -> Is a 404
johnklos 3y ago
Yeah - the whole "sudo" category just seems superfluous since the issue is with sudo, not with the individual tools. OTOH, if people are expecting literally every program to open file handles / network sockets, then drop privileges to something else, that's a weird expectation. I'm in the no sudo camp myself.

simonblack 3y ago

I've got a system without sudo Yes, I hate sudo's unwieldiness too. The very first thing I do after installing one of those distros that default to no-root-login (Ubuntu, Mint, etc) is to give root a password. The downside is that I allow "root SSH", contrarily to every single best practice out there. Why can't you log in via SSH as a 'normal' user, and then "su -" to become root? I use that method, and it obviates both the use of sudo and the allowance of "root SSH".

tiffanyh 3y ago

OpenBSD sudo replacement, “doas”, plus them reworking the need for root to run services - address above. https://man.openbsd.org/doas https://man.openbsd.org/doas

GuB-42 3y ago

These bypasses are typically not for when are the only user and also the administrator. Sudo here is not really for securing your machine: as others have said, if an attacker gets to your personal account, it is game other. It is mostly a tool for you to avoid fucking up your system by mistake. These bypasses are useful if you want to get root access on a machine you are given some, but not all administrative rights, like a shell and a few sudo commands, for example to restart a service.

voxadam 3y ago

Do you also disallow su on your system or is it just sudo that's been banished? Edit: I'm curious because if you still allow su on the system there seems to be little to no reason to set PermitRootLogin in sshd_config regardless of auth mechanism (password, cert, token, etc.).

fuzztester 3y ago
Yes, good question. Because su was there in Unix before sudo, IIRC. And sudo means "su do", meaning do (something) as su, which in turn meant "super user" or "substitute user" according to Wikipedia, since it can also be used to login as other users than root , e.g.: su - tom https://en.m.wikipedia.org/wiki/Su_(Unix) https://en.m.wikipedia.org/wiki/Su_(Unix)

alufers 3y ago

Out of curiosity: What sensitive things does the root account protect on your workstation? On my desktop (and probably 99% of people's desktops here) getting access to the user account is game over. The password manager? Runs as my user - one ptrace and the key can be extracted. Cookies for all my online services? Sitting right there in the home directory. The only thing root access would give somebody on my machine is to uninstall some random packages or corrupt my install. And don't get me wrong, I don't like this situation - I tried running some high-risk programs (browser, Libre Office) under flatpak to achieve at least some separation - but it breaks too many things.

drbawb 3y ago
On my system the root account is primarily for upgrades, but also storage administration! ZFS snapshots protects me against silly mistakes like strange permutations of `rm -rf ~/` in day to day operations. Not having root all the time protects me against `zfs destroy -r nagato/data/home/drbawb` which will nuke my home folder, 144 frequent snapshots (15 minute intervals per 36 hours), 14 daily snapshots, 4 weekly snapshots, and 3 monthly snapshots. That would suck. A lot. (I have a file called "RIP", where a drive image used to be mounted, because I got a little too over-zealous with the recursive option on some ZFS commands on a file that had `copies=1`. _RAID is not a backup, snapshots are not a backup, etc._) This also means that theoretically ransomware (running without root) could encrypt my home directory, but apart from doubling the number of blocks used on disk it would have no real impact on my data. (If someone writes a virus that can encrypt the blocks inside a ZFS partition, without mangling ZFS data structures beyond repair, then I'll be more impressed than angry. Not even the ZFS devs can rewrite block pointers on a running filesystem.[1]) That being said ZFS has an awesome feature called delegation which lets you run a subset of commands without root permissions. I use it sparingly, mostly to allow unprivileged backups. (Each host gets a login on my backup server, and can only create/destroy datasets that are children of a host-specific dataset. So `nagato` can `zfs destroy -r backup/hosts/nagato` but not `zfs destroy -r backup/hosts` or `zfs destroy -r backup/hosts/someone-else`.) [1]: https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s https://www.youtube.com/watch?v=G2vIdPmsnTI#t=44m53s
mormegil 3y ago
Yeah, that's the classic https://xkcd.com/1200/ https://xkcd.com/1200/ I thought about using Qubes OS on my new computer but it seemed like a lot of work and tweaking and still having to live with the limitations so I abandoned the idea.

mike_hock 3y ago

They don't rely on sudo. The sudo tag merely indicates that if sudo is configured to allow "your" (the pwned) user account to run them, they can also be used for privileged operations that might not have been intended by whoever configured sudo that way. "Never allow root SSH" together with the strong implication that it should be used in conjunction with sudo, has always had a very weak rationale behind it, since as soon as you actually ever make use of sudo to elevate your privileges, for an attacker there is almost no meaningful distinction between your user account and plain root. Looking at the historic reality, the weak rationale more than evaporates completely. Due to various CVEs, sudo has, in retrospect, been a trojan horse for most of its existence that allowed privilege escalation from any user account regardless of its configuration. The period for which sudo has had these vulnerabilities overlaps rather well with the period for which it has been championed as "best practice" along with the tenuous justifications based on security by obscurity and to avoid "user mistakes." In that light, your setup seems perfectly sane to me, however I don't believe sudo is relevant as a backdoor anymore in 2023 and the focus has most likely shifted to something else.

tureu92 3y ago

I think at this point you are solving a wrong problem. Getting root access through X zero days exploits is not so hard. And if you uninstall `sudo` and `su`, and only login as root on dedicated TTY, you have very similar security. I use Qubes OS for stuff like this. Way better security, no need to juggle tokens, dedicated lans and so on. Only real problem is no graphical acceleration in browser (Google Earth...)

chaxor 3y ago
Doesn't Qubes require like 32GB of RAM just to run? I would love to use it, but most of the use cases I would like to try it for are much more in the realm of SBCs with 2-8GB of RAM for running services locally. It would be great to have that extra security, but the cost is really really high.
- tureu92 3y ago
  systemd-nspawn...
- colejohnson66 3y ago
  > Doesn't Qubes require like 32GB of RAM just to run? 32 GB minimum, but 16 GB recommended.[0] I think that's backwards, so I'd say it's actually 16, not 32 required. But yes, that's more than a typical SBC will have. The Pi 4, for example, has a maximum configuration of 8 GB, but some have modded it to have 16 GB.[1] [0]: https://www.qubes-os.org/doc/system-requirements/ https://www.qubes-os.org/doc/system-requirements/ [1]: https://www.techradar.com/news/a-raspberry-pi-4-with-16gb-its-been-done-but-theres-a-big-catch https://www.techradar.com/news/a-raspberry-pi-4-with-16gb-it...
  - bazodedo 3y ago
    I was curios about that 16GB pi. (I want to have one myself :) Unfortunately, it looks like soldering the 16gb ram chip onto the pi did not increase the usable memory due to other hardware limitations. [1] https://forums.raspberrypi.com/viewtopic.php?t=350514 https://forums.raspberrypi.com/viewtopic.php?t=350514

gsich 3y ago

>The downside is that I allow "root SSH", contrarily to every single best practice out there. The upside... Well. Is that there's no "sudo" installed on my workstation. Allowing root login is fine. The best practice is not to allow passwords for root login.

TacticalCoder 3y ago
> The best practice is not to allow passwords for root login. My sshd is configured to not allow passwords logins at all: it's U2F/Yubikey only.
- gsich 3y ago
  I somewhat like smartcards more. Takes use of the slot, not wasting rare USB ports on notebooks. I don't why there are so few USB ports, but that's another discussion.
johnklos 3y ago
The even better than "best" practice is to not allow passwords for any login. Keys really aren't that hard.

chasil 3y ago

Did you remove all of these? $ cd /usr/bin $ for x in ./*; do [ -u "$x" ] && printf "$x\\n"; done ./at ./atq ./atrm ./chage ./chfn ./chsh ./crontab ./fusermount ./fusermount3 ./gpasswd ./mount ./newgrp ./passwd ./pkexec ./sg ./staprun ./su ./sudo ./sudoedit ./umount ./vmware-user ./vmware-user-suid-wrapper $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) I notice that chsh is not on the list of the parent article.

TacticalCoder 3y ago
> Did you remove all of these? So if you can't protect versus all the threats, you may as well not do anything?
- chasil 3y ago
  Perhaps a more reasoned approach would be to rewrite them in rust, or some other hardened language for greater security.
sigotirandolas 3y ago
What really matters is not whether you have sudo (or su, pkexec, etc.) installed, but rather that you never, ever escalate privileges from a less trustworthy user to a more privileged one, since at a conceptual level this combines the low trustworthiness with the high privileged-ness. Instead, when you want to elevate privileges, you should do so by using a mechanism that takes the control of the machine away from less trustworthy user - such as a Secure Attention Key or similar mechanism.
- chasil 3y ago
  But all of these programs escalate privileges from less trustworthy to more. $ ls -l /usr/bin/passwd -rwsr-xr-x. 1 root root 33424 Apr 1 2022 /usr/bin/passwd The "s" above indicates that the program is allowed to call the setuid() family of functions to alter the real, effective, and/or saved user id. You would not be able to change your password without the functionality.

jonas-w 3y ago

None of them rely on sudo. https://gtfobins.github.io/gtfobins/sudo/ https://gtfobins.github.io/gtfobins/sudo/ -> Is a 404

johnklos 3y ago

Yeah - the whole "sudo" category just seems superfluous since the issue is with sudo, not with the individual tools. OTOH, if people are expecting literally every program to open file handles / network sockets, then drop privileges to something else, that's a weird expectation. I'm in the no sudo camp myself.