Posted Sep 26, 2004 0:51 UTC (Sun) by pimlott
In reply to: Complexity
Parent article: An introduction to SELinux
So you suggest to write a wrapper for each program multiplied by the number of users?
A single "runas" setuid root program, along with a database containing the user hierarchy, would be sufficient. I was just pointing out that users could create their own setuid programs for whatever reason, though they should restrict access to them. All straightforward with vanilla unix semantics--I disagree that this is anywhere near as complicated as SELinux.
I feel that the current Unix security model just for system daemons is woefully inadequate
Your point about sshd is interesting, because I think I can use this to illustrate the "unix way". Of course, you know about privsep. The process that processes network connections has "no" privileges. (Of course it has some, but this is a separate issue; it should be possible to run the child as a user who can do nothing but talk to the parent and the network.) When the client authenticates, the child passes a "proof" to the parent, which sharts a user shell. I think the notion of a high-privilege daemon that executes requests from a low-privilege uid upon suitable proof should be a standard unix service. There's a project called userv that tried to do this.
Now, there is still the problem that the privileged process runs as root. You could say it's just part of the trusted base (which might make even more sense if it were generalized as suggested above). But if you'd like to do better, one idea would be to use the "master user" idea I mentioned before: Allow a uid to switch to any uid of which it is a master, and have the sshd privileged process run as a master of all users who are able to log in remotely.
(SELinux solves the second part in its own way, but obviously does not remove the need for privsep.)
Most daemons are much simpler than sshd in that they don't need to switch to other users based on network input. Those should be much easier to move away from root, and of course some have been. Some changes ought to be made in how access to the network (binding low ports, sending raw packets) is controlled. You might argue that if this is so easy within the unix model, why aren't we further along? I don't have a great answer. Maybe it is people don't care enough about security to do it. Maybe it's because the devil is in the details: figuring out exactly which privileges a daemon needs is hard (as the SELinux people have found out themselves). Maybe all the people who could do it have been seduced by SELinux. ;-)
I don't see how you can even get close to getting rid of all the uid 0 daemons on the system today.
In theory, it's the same process as tightening down a daemon with SELinux: Move it to a user with no privileges, run it, see what breaks, and figure out how to give the user the necessary access (or change the daemon).
We just disagree on whether your model is actually a significant improvement or not :)
Yes, but I remain optimistic. I still think your view is tainted by the historically insecure unix implementation(s), and so you don't give the unix model a chance. Maybe in a few years SELinux will be mainstream and make Linux so secure that this will all be moot. But I'm skeptical that it will gain the necessary acceptance and usability. Or maybe I'm just too tied to unix tradition, and the new SELinux generation will prove me wrong!
to post comments)