Wandering Thoughts archives

2007-04-23

Extra security systems for Unix should be explicit, not implicit

I'm no fan of SELinux, but in stumbling over it a few times I've come to some theories about why I don't think it works. One of them, perhaps the most important one, is this:

Extra Unix security stuff needs to be simple and explicit.

Extra Unix security stuff needs to be explicit because the effective alternative is invisibility, since Unix already has one security system and most people aren't going to do very well remembering a second invisible one.

(A great deal of SELinux is implicit, in file contexts and so on, so when something goes wrong it is a mysterious failure with an invisible cause. The very existence of setroubleshoot, whose purpose is to try to make SELinux less invisible, shows the problem acutely.)

One simple change that would make SELinux a lot less invisible would be to give it its own errno value, with an accompanying useful error string. Then programs that fail because of some SELinux ailment might at least print something that points people to the cause, instead of a 'permission failed' message that just leaves the poor sysadmin frustrated because as far as they can see, the permissions are fine.

(Similar logic applies to remote filesystems; if the client thinks that everything should be OK but the server disagrees, I think you probably want to return a different errno value to the program. I'm aware that no one agrees with me here.)

A corollary to this is that I think process confinement should be an extra mechanism and be explicit; one mechanism would be that you just run a program like su to start programs in the confined setting of your choice. Then you could at least see this in places like startup scripts, and you could try it out by hand, and so on.

(I don't have a good answer for how confined processes should show up in ps output. Perhaps every confinement mode should have a UID and login assigned to it, although then you'd want the kernel to either automatically confine processes running as that UID or refuse to allow you to become that UID outside of the confinement system, so you can never have a process running as that UID that is not confined.)

unix/ExplicitExtraSecurity written at 22:49:34; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.