3 ms·
Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'. Plus you only need
by mort96 6mo ago
Yes, that would be one potential solution. But I have certainly never done it and bet >99.999% of the world's use of sudo is through 'sudo'.
Plus you only need one slip-up and you're hosed. Even people who try to almost always use '/usr/bin/sudo' will undoubtedly accidentally let a 'sudo' go through. Maybe they copy/paste a command from somewhere (after verifying that it's safe of course) and just didn't think of the sudo issue then and there.
- sinsudo 6mo agoThe real problem is that there should be at least 2 levels for sudo, one for installing software and another that really allows someone to compromise the entire system, both layers should be separate to mitigate risk. At least the most secure layer should allow you to perform secure recovering and diagnosis
- DonHopkins 6mo agoUnix used to have a user named "bin" just for owning all the binaries and performing installs.
- sinsudo 6mo agoThe old bin user is an idea that could be modernized with a new two level sudo concept, the higher one for recovery and diagnosis, already done in Chromebook and other solutions
- DonHopkins 6mo agobin passwords I will always remember: At the University of Maryland CS department systems the bin password was "fuck,you", and there was a devout Christian student on staff who had a problem with that, so we had to change it (to something harder to remember, I just can't recall).
- lrvick 6mo agoYou do not need sudo for installing software. Can just install to ~/.local. Many package managers require sudo, sure, but there is no good reason for them to in a modern linux system, and not all require this. Even with systemd, you can use systemd --user.
- michaelmior 6mo agoThat depends on what the software is. If you want to run a service that bonds to a privileged port for example, you need sudo.
- signed-log 6mo agoFor most things, you can do with capabilities Issue is that it increases friction and you need sudo anyways to set the capabilities. Most web servers would happy to run unprivileged with only CAP_NET_BIND_SERVICE
- lrvick 6mo agoIf you set the appropriate linux capabilities flag on a binary such as sshd at bootup then unprivileged users can bind to 22, no problem. setcap 'cap_net_bind_service=+ep' /usr/sbin/sshd Could even run it as a daemon unprivileged from a home directory with "systemd --user" That said if you have multiple users and want every user to have their own sshd reachable on port 22 on the same machine you probably want to listen on vhost namespaced unix sockets and have something like haproxy listen on port 22 instead. Haproxy could of course also run unprivileged provided it has read access to all the sockets.
- mort96 6mo agoHow do you setcap without root?
- lrvick 6mo agoThe way many including me manage systems without root privileges at runtime is by compiling immutable rootfs images that run in ram with kernel, init, mounting filesystems and assigning any users and privilege assignments, then drop to user privs. That stuff needs to change very seldom, so when you do need to change it you just generate a new tiny rootfs image in a few seconds and reboot to pivot to it or maybe have a kexec trigger if you are feeling fancy. For my primary workstation the entire disk is my home partition and I boot my latest rootfs from a flash drive. In other cases network boot.
- DaSHacka 6mo agoMore than just two levels for sudo, the Linux permission model is completely broken for this very reason. (Also see: https://xkcd.com/1200/ https://xkcd.com/1200/) Honestly, the Android approach is significantly better. (and for that, see Micay's various ramblings posted online)