282
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.
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.
You must fear hammers.
Walk me through that analogy, and what point you're trying to make. My hammer doesn't typically have unexpected interactions with things I'm not hammering. When I build a bookshelf, I don't have to make sure my desk is clean to keep people I let borrow books from unlocking my front door without a key.
Do you think that improper setuid isn't a common enough vulnerability to have a name and designation?
What constitutes a security nightmare if not something that requires a large and annoying amount of work, and can be made insecure by a mistake somewhere else?
Hard agree. This is why rust is getting so much attention, and the c/c++ crowd are so mad. They're happy just blaming it on a "skill issue" while losing their shit over [the rust crowd] saying "how about we don't let you in the first place."
Or maybe I just think that Rust has crappy design, just like JavaScript. The suid question is of a different kind: capabilities is better because they are an expression of least-required-permission principle, and going this way can't be argued as a skill issue
It's OK, you don't have to use so many words to tell us you work with c.
wrong guess. I work mainly in PHP
And you're complaining about rust?
Complaining? No, I counter your evangelistic attitude that whoever does not like Rust is just self-important elitist. That kind of people does exist, but not liking Rust is not a sign. Cheers
Sure, but that was a strong response for a comment on the situation. Sounds like you care. I do not. π
Lol. Changing shoes in the air? Your root comment literally starts with word "hard"
Hard agree to setuid being a problem. And that it is a problem because any of these tools written in c can be a security hole, because c is hard to get right. And I find it funny that c devs are butthurt over how rust won't let them write obviously bad code.
But it's OK, words are difficult. π
And now you do not care so much that this comment tree is already hilariously long, and also has two of your emojis used to hide your true emotions. As much as I would love to discuss how c devs are "butthurt" and Rust is so damn good (sarcasm, of course), I just won't do it with someone so full of themselves and insecure. Have a good day
You continue responding. You are as complicit in this thread as I am. π