A little introduction first; I'm currently working on a little operating system project of my own, putting together my initial design spec, and I was wondering if the readers of this list wouldn't mind helping me refine my (I expect) fairly simplistic ideas? If not, please just ignore this message.
Anyway, I've been looking at ways to implement security, and from what I've
read, I'm attracted to the capability solution (well, obviously). But from
my current understanding of what I've read, it's not possible to have a
*pure* capability system without also having persistence, right? (And,
unfortunately, that's not the way I'd ideally like to go...) I suppose it
would be possible to have a dedicated store of all the capabilities
belonging to every program in the system, but I'd imagine that that would
get unmanageable very quickly.
So far, that doesn't get us any further than a conventional ACL system.
The change we make is that we have - as you would with this system - checking of ACLs only at the point that the capability is obtained, and allow capabilities to be passed freely from process to process.
So we create a system utility - call it untrust - which users can use to run programs they don't want to execute with their full rights. So for the example of the untrusted finance program, for example, the user could specify:
untrust r=inputfile w=outputfile -tempfiles "finance < inputfile > outputfile"
to pass on only her capabilities to read and write the data files it needs to have access to, and, say, her temporary-space-usage capability. That would be implemented by having untrust pass on to the finance program a capability to itself rather than to aclmaster - so that it could reject out of have any request for a capability the user had not explicitly specified should be granted, before forwarding the request to aclmaster.
The same thing would apply to, for example, system services such as e-mail servers, which would receive a capability for a trusted service manager program rather than for aclmaster; it would limit their rights in the same way, and because the service manager would never communicate with the outside directly, it wouldn't be susceptible to compromise in the same way as the services themselves.
I think that gets back the "access restriction" and "collaboration" abilities. It doesn't, alas, solve the "privileged programs" one in the same way, without implementing some dreadful hack like being able to grant a capability to an executable that will be unreadably stored with it but sliced-off the next time that file is touched by any non-read/execute operation, or turn any setuid-equivalent programs into continuously-running system services that get their capabilities from the kernel direct, but that's almost as bad.
So the "confused deputy" would still be with me. I wish I'd realised this at the start of this e-mail... Oh, well. Any comments or ideas, please?
Thanks in advance,
Alistair