Navigation | ||
My WhyNot? | ||
Icon Key | ||||||||||||
The community's level of support for this idea is...
| ||||||||||||
root means suid | |||||||||||||||||
One of the gotchas of computer security for (corporate) networks is the risk of privilege elevation from running someone else's code. Let's say you have a user, Malice. Malice is a pleasant and knowledgable user who writes small programs for their own use. You might try a program under an ordinary user account, just to see what it does, and it doesn't misbehave. No attempts to do anything suspicious. It looks safe. Sucker! As soon as you run the code as root, it detects the uid and adds a backdoor into the system, then covers it's tracks. Bait-and-switch! Of course, you'd never trust a user like that, would you? Or a supplier, or a consultant, or a boss, or ... You get my point. Whenever you run code belonging to a lower-privileged user, you risk a privilege elevation. Trust no-one. Unfortunately, life being what it is, you will let your guard down and run something when you shouldn't. What you need is a bit of safety built into the computer. The idea: Whenever root - and only root - runs a program or script, the program/script is treated as if it were suid. This way, if you run someone else's code as root, your godhood is revoked while the code is run. No mess, no fuss. This idea can be extended to more complicated (e.g. MS) schemes by substituting the rule "If the user has a higher privilege level than the code-owner, then suid." or "If the user has a higher privilege level than the lowest-privilege user who can/did write to the file, then suid.".
nihil, Aug 06 2005
What do you think of this idea or comment?
| |||||||||||||||||
I agree
No opinion
I disagreeUsers who liked this idea also liked: | ||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||
Add your comment
I guess I don't understand the terminology being used here, but I thought that "suid" stood for "super-user ID"-- in other words, "root". So, is this a Unix command, or is it general computing terminology?
Anyway, it sounds like a reasonable precaution.
dumllama: suid = set user id
First off, this wouldn't help. It'd be trivial for the program to seteuid() back to its real user id — that is, root. Unprivileged processes are allowed to set the effective user id back to the real user id.
Second, it'd cause problems --- assumably, you ran the program as root for a reason. Maybe to listen on a port < 1024, maybe to access a file only root can, whatever. That'd break.
Third, it seems rather pointless. How do you accidentally run a program owned by someone else? No one else should be allowed to modify directories in root's PATH, so they can't put it there in the first place. If other have write access to those directories, you have bigger problems.
This already exists and any good system administrator can implement it on code that you never want to run as root.
Take any service account like foouser
And take any program like foobar
Make the service account own the program
chown foouser foobar
Now set the UID bit for execution on foobar (and the execute permissions)
chmod 4755 foobar
Your idea was great, but it was originally introduced in Unix over 35 years ago. The people who normally have root dont necessarily know how to use it. So the real idea is educate system administors to do things like you recommend to proactively avoid problems .. like that is ever gonna happen ...