| |||||||||||||
ComplexityComplexityPosted Sep 23, 2004 20:29 UTC (Thu) by pimlott (guest, #1535)In reply to: Complexity by walters Parent article: An introduction to SELinux
Strong, mandatory access control helps contain a lot of the problems that we see every day on LWN's daily security advisory summary. Of course I agree that we need better compartmentalization. But you're begging the question with the assumption that MAC is the only way to do it. You can do a lot with uids. It seems perfectly plausible to me that mozilla court run under a uid that has access to a subset of my files. (It probably needs some extensions to the unix model, but relatively modest ones.) BTW, what if the user wants to send his .gnupg config file in a gpg bug report? Does he have to edit a policy that even SELinux advocates seem to acknowledge can only be understood by experts? Or does he just change permissions on the file?
The NSA aren't the only ones who need this kind of strong security. When I said only the NSA needs this, I was thinking about controlling information leaks, not compartmentalization. Preventing intentional leaks is extremely hard, even with MAC. You can't really do it; at best, you can slow it down or make it detectable. And it's not practical at all without a lot of resources.
As for extending the uid system - I'm very doubtful that you can get a system that approaches the security and flexibility that SELinux provides, and that also doesn't break existing software. I wish we had a test to find out! And I'm not necessarily aiming for all the flexibility you get with SELinux. (BTW, I consider the statement that any system "provides security" to be sloppy.) And considering how difficult it has proven to deploy SELinux at all, I'm fairly sure that a less radical change would cause less breakage.
(Log in to post comments)
Complexity Posted Sep 23, 2004 22:10 UTC (Thu) by walters (subscriber, #7396) [Link] How do you propose to transition uids? How to keep them unique? What about the problem of applications which will want to look up little details like the home directory or user name in /etc/passwd? How do I grant access to this new uid for certain objects?
That's just a random selection of generic problems.
Now, even if you ran mozilla under a separate uid, you'd have to grant it access to your X connection. And at that point, you've lost, since with X any malicious client can sniff keystrokes, spawn a terminal and synthesize rm -rf / into it, etc.
SELinux doesn't solve that either right now - but it will, once we have Security-Enhanced X. And that's already in development.
Complexity Posted Sep 23, 2004 23:16 UTC (Thu) by pimlott (guest, #1535) [Link] How do you propose to transition uids? How to keep them unique? What about the problem of applications which will want to look up little details like the home directory or user name in /etc/passwd? These issues seem easy (but bear in mind these are answers I've made up on my own and never tried!). You have a setuid program that allocates additional uids to a user, puts them in /etc/passwd and everything. (Or maybe you pre-allocate a pool of "sub-users" when you create a user.) By default, they would probably have the same home directory, etc as the "main" uid.
How do I grant access to this new uid for certain objects? The short answer is with usual unix permissions, but here it gets harder. You probably at least want to let users allocate their own groups, and since groups are not that flexible, you probably want ACLs as well. (But ACLs are becoming more common anyway.) Further, you may need to add a notion of relationships between users, so one user might be a "master" of another and be able to chown or chmod his files. This is where I think a genuine extension may be needed, because in traditional unix, every user is an "island".
Now, even if you ran mozilla under a separate uid, you'd have to grant it access to your X connection. Yes, this is a hard problem, but again you're begging the question when you say SELinux is the answer. A secure, multi-domain X server can just as well be based on uids (or cryptographic keys) as on SELinux. You seem to equate compartmentalization with SELinux, and I think that's simply an unwarranted assumption.
Complexity Posted Sep 24, 2004 2:29 UTC (Fri) by walters (subscriber, #7396) [Link] You didn't try to explain transitioning. But really there are so many problems with this scheme it's hard to know where to start. And even if it all sort of worked, it wouldn't be good enough for me. For one thing, it's still totally screwed if there's an exploitable setuid root program. Also any system service running as root, once cracked, compromises the entire system. I just don't think anyone is really interested in a halfway solution to security like this.
Complexity Posted Sep 24, 2004 19:27 UTC (Fri) by pimlott (guest, #1535) [Link] You didn't try to explain transitioning. Oh, I didn't get what you meant by transitioning before. You mean switching to a new uid? What's difficult about that? You can write your own setuid wrappers, or call a system setuid root program that lets you drop to any sub-user.
But really there are so many problems with this scheme it's hard to know where to start. I don't think that's a fair way of arguing, and I don't think this discussion has supported that position. Look, we already use uids and namespaces (chroot) to good effect (though not nearly enough) for isolating system services. Bringing this technique to ordinary users seems both plausible and natural to me.
And even if it all sort of worked, it wouldn't be good enough for me. I think your view on security is too absolutist. You use a computer today, right, even knowing how crappy our security is? Getting to nirvana should not be the goal, making significant improvements should. (And no, I am not ceding that SELinux is ultimately more secure than my system could be. There are way too many factors that go into security to say that SELinux is more secure just because it has a nice design.)
For one thing, it's still totally screwed if there's an exploitable setuid root program. This statement is equivalent to saying, it's screwed if there's a vulnerability in the trusted base. This is true of any system. BTW, there's no reason you can't write all the setuid root programs in a safe language (which is not practical for in-kernel code).
Complexity Posted Sep 24, 2004 20:24 UTC (Fri) by walters (subscriber, #7396) [Link] Oh, I didn't get what you meant by transitioning before. You mean switching to a new uid? What's difficult about that? You can write your own setuid wrappers, or call a system setuid root program that lets you drop to any sub-user. So you suggest to write a wrapper for each program multiplied by the number of users? And how do you prevent other users from executing the programs which are setuid to a subuser of another user? A massive system setuid program would require a complex configuration to map out the allowed transitions. This is just the start of the problems, in the end you're going to have something that's much weaker than SELinux and is no less complex. I don't think that's a fair way of arguing, and I don't think this discussion has supported that position. Look, we already use uids and namespaces (chroot) to good effect (though not nearly enough) for isolating system services. Bringing this technique to ordinary users seems both plausible and natural to me. Here you and I have a fundamental difference. I feel that the current Unix security model just for system daemons is woefully inadequate, completely disregarding users. For example, one cool thing you can do with SELinux now is set up sshd so you can log in as a normal user (user_t), but not as sysadm_r (the SELinux equivalent to "root"). Even supposing you crack sshd and compromise it fully, the SELinux policy prevents sshd from executing anything with elevated privilges. Sure, it has uid 0, but that doesn't matter with SELinux. Another good example of a problem that SELinux solves that your scheme never would is prevention of /tmp races. Right now, the "staff" type in SELinux (an unprivileged role used by someone who can become a sysadm) simply cannot read files created by the user type. So when the attacker creates a symlink /tmp/predictable_file_name -> /etc/passwd, even if the attacker makes the symlink world-readable, it still won't work. I could go on here, but I hope the point is made. I think your view on security is too absolutist. You use a computer today, right, even knowing how crappy our security is? Getting to nirvana should not be the goal, making significant improvements should. Right, I agree. We just disagree on whether your model is actually a significant improvement or not :) This statement is equivalent to saying, it's screwed if there's a vulnerability in the trusted base. This is true of any system. BTW, there's no reason you can't write all the setuid root programs in a safe language (which is not practical for in-kernel code). Yes, but in SELinux, only the kernel is the trusted computing base. In your model, anything with uid 0 can fully compromise any part of the system. setuid root programs are only a part of this problem. I don't see how you can even get close to getting rid of all the uid 0 daemons on the system today. cron, dbus, dhcp, inetd...the list is huge. SELinux is a much easier and much more secure solution.
Complexity Posted Sep 26, 2004 0:51 UTC (Sun) by pimlott (guest, #1535) [Link] 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!
|
|||||||||||||