This week on "ancient unix hacks that are still somehow a core part of linux": Setuid
This week on "ancient unix hacks that are still somehow a core part of linux": Setuid
Explanation for newbies: setuid is a special permission bit that makes an executable run with the permissions of its owner rather than the user executing it. This is often used to let a user run a specific program as root without having sudo access.
If this sounds like a security nightmare, that's because it is.
In linux, setuid is slowly being phased out by Capabilities. An example of this is the ping command which used to need setuid in order to create raw sockets, but now just needs the cap_net_raw capability. More info: https://unix.stackexchange.com/questions/382771/why-does-ping-need-setuid-permission. Nevertheless, many linux distros still ship with setuid executables, for example passwd from the shadow-utils package.
If this sounds like a security nightmare, that’s because it is.
You can perfectly-reasonably implement suid binaries securely. They need to be simple and carefully constructed, and there shouldn't be many of them, but the assertion that suid is "a security nightmare" is ridiculous.
sudoitself relies on the suid bit.They need to be simple and carefully constructed
Yeah, that's the difficult part. It's always better to go with the principle of least privilege (which is Capabilities is trying to do) than to just cross your fingers and hope that there are not bugs in your code. And who exactly is going to police people to make sure that their programs are "simple and carefully constructed"? The article I linked is about a setuid-related vuln in goddamn Xorg which is anything but.
Yes, Xorg being suid is stupid. That used to be needed due to several historical reasons, but is not any more.
But for 'su' or 'sudo' suid is still the right mechanism to use. Capabilities won't help, when the tool is supposed to give one full privileges. Of course, in some use cases no such command is needed, then the system can run with no suid. Similar functionality could be implemented without suid too (e.g. ssh to localhost), but with its own security implications, usually bigger than those brought but a mechanism as simple as suid (the KISS rule).
I would describe need to proactively go out of your way to ensure a program is simple, minimal, and carefully constructed to avoid interactions potentially outside of a restricted security scope as a "security nightmare".
Being possible to do right or being necessary in some cases at the moment doesn't erase the downsides.
It's the opposite of secure by default. It throws the door wide open and leaves it to the developer and distro maintainer to make sure there's nothing dangerous in the room and that only the right doors are opened. Since these are usually not coordinated, it's entirely possible for a change or oversight by the developer to open a hole in multiple distros.
In a less nightmarish system a program starting to do something it wasn't before that should be restricted is for the user to get denied, not for it to fail open.https://www.cve.org/CVERecord/SearchResults?query=Setuid
It may be possible, but it's got the hallmarks of a nightmare too.
Last time I was tempted to use suid, it was in order to allow an application I'd written to listen on 80 and 443. Fortunately I found the capabilities way of doing that (
setcap 'cap_net_bind_service=+ep' executable) and that was the first I ever heard of capabilities. I consider myself pretty Linux-savvy, but it was pretty recently that I learned about capabilities.Another potential option here is https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html
ip_unprivileged_port_start - INTEGER This is a per-namespace sysctl. It defines the first unprivileged port in the network namespace. Privileged ports require root or CAP_NET_BIND_SERVICE in order to bind to them. To disable all privileged ports, set this to 0. They must not overlap with the ip_local_port_range. Default: 1024This is also per namespace so you could use it in combination with network namespaces if you really wanted to keep privileged ports.
I just run everything as root
What security
fork bomb still being possible out of the box in a couple of characters is funny to me
That's the thing about Linux. The developers generally assume you want to do the thing you're doing. So they don't stop you.
ah the parenting toddlers approach
And I am eternally grateful for that. Why, yes, if I am playing with something I don't understand - what was the last time a fire gently asked anyone "Do you really want to get a burn?"
The
nosuidmount option disables this behavior per mount. Just be sure you don't use suid binaries.Example:
sudoordoas. I replaced those with switching to a tty with an already open root account on startup. Generally faster and (for me) more secure (you need physical access to get to the tty).Does run0 use suid? From my understanding, it shouldn't.
From what I've read, no. Though it doesn't solve the fundamental problem of a root process handling untrusted input from a regular user.
The TTY method is IMO better as it ties privileges to a piece of physical hardware, bypassing the complexities of userspace elevation of privileges.
So you can't become root on your system unless you switch to that tty? That sounds like a gigantic pain in the ass.
But how am I going to use capabilities to have my equivalent of
slhaving setuid tonobody?Oops