Posted Sep 24, 2004 20:24 UTC (Fri) by walters
In reply to: Complexity
Parent article: An introduction to SELinux
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.
to post comments)