Ghosts of Unix past, part 3: Unfixable designs [LWN.net]

Ghosts of Unix past, part 3: Unfixable designs

Posted Nov 18, 2010 23:11 UTC (Thu) by skissane (subscriber, #38675)
Parent article: Ghosts of Unix past, part 3: Unfixable designs

Regarding permissions, I think they ideally should not be stored with the files, but in some kind of separate security database. Then, one can easily review and manage them in aggregate. Much safer than littering the file system with them.

I don't think evaluating access control should belong in the kernel. Policy questions like this should be handled by a trusted user space process. When a process tries to access a resource, the kernel should ask the security daemon if it is OK. The security daemon can do whatever you want to answer that, and then just tell the kernel permit or deny. There could be several different security daemons to choose from, depending on needs. A smartphone, or home users desktop, will have very different needs from a server operated by an intelligence agency - rather than one system to fit all needs, multiple systems for different needs may be better.

In principle, what I am suggesting is similar to how I understand RACF (and TopSecret and ACF2) work on IBM mainframes. (OK, not all the associated mainframe-warts, but I think the basic idea is good.) The security software is an add-on to the base OS, the base OS just exposes standard hooks for the security software to integrate with.

To avoid the performance hit of constantly context-switching to the security daemon, the kernel should have some kind of cache. That way, first time process tries to access a resource, kernel asks security daemon for OK. If daemon says yes, then kernel remembers and doesn't need to ask again. If everything is a file descriptor, a good time to do this would be at OPEN time - the kernel asks once when FD is open what access will be permitted for that FD, then remembers that for duration of FD.

I suppose this is the classical capability architecture - if everything is an FD (or in Windows-ese, a "handle"), then we can merge the concepts of FDs with capabilities. And a security daemon is then used at FD/handle creation time to determine for the lifetime of the FD/handle what it can do. It might need to be consulted occasionally once FD is created - e.g. is it OK to pass this FD to another process? Also, if the security permissions are revoked while FD is open, the daemon should be able to ask kernel to forcibly close, or downgrade the rights, of an FD it earlier approved to be opened.

(Log in to post comments)

Ghosts of Unix past, part 3: Unfixable designs

Posted Nov 20, 2010 0:32 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

You've hit the nail on the head better than any of the other comments or the article itself, by talking not about what the right permission scheme for all future applications is, but a fixable design that lets us recover if we pick the wrong permission scheme today.

Incidentally, I think the separateness of RACF happened out of necessity more than architecture. The filesystem formats were already cast in stone with no concept of permissions whatsoever in them. There was no concept of a user identity either. I don't know if designers of RACF considered building all that into the supervisor code and felt it would be less fixable that way or just that it would be harder, but I do like the result.

RACF and its alternatives also encompass resources other than files.

I think there are plentiful examples of this on Linux too, but I don't follow those things. Selinux? AppArmor?

Ghosts of Unix past, part 3: Unfixable designs

Posted Nov 25, 2010 20:18 UTC (Thu) by slashdot (guest, #22014) [Link]

Linux does this, although security is handled by kernel modules ("LSM"s) instead of daemons.

AppArmor has separately-stored policy, while SELinux has separately-stored policy which is however automatically baked into the filesystem.

The real problem Linux has is that nobody seems to have the interest, authority and/or ability to figure out the optimal security model to use, so there are several ones in wide use, but none is actually polished and widespread.

Also, security UI and user-friendliness work seems quite lacking, with the result that advanced security often gets just turned off and even if enabled, only distribution-provided policies tend to be used.