Messages in this thread | | | From | Malcolm Beattie <> | Subject | Re: PROPOSAL: Process Authentication Groups (PAGs) (fwd) | Date | Mon, 23 Feb 1998 11:12:36 +0000 (GMT) |
| |
Robert Watson writes: > On Fri, 20 Feb 1998, Peter J. Braam wrote: > > > On 20 Feb 1998, Aaron M. Ucko wrote: > > > > > Absolutely. However, it's not clear PAGs a la AFS are the right > > > solution. IMO, token sets (TS's for short, pending a better name) > > > should have the following properties: > > > > The purpose of a PAG is NOT to do token management, but to provide > > identity to token managers. > > Given the requirements of Coda/AFS/other file systems, PAG does suffice. > It covers correctly, thus far, all cases for either PAG inheritence (or > lack thereof) that have been described to me. However, the PAG is not a > general solution to the problem of UIDs in UNIX. It is unlikely, however, > that the Coda project will be able to address the short-comings of the > UNIX authentication/authorization model. These are certainly issues that > need to be addressed, but not in this forum. Possible solutions to the > problem do include Token-managing support in the kernel. The > implementation of "superior UNIX auth*" is a very long-term project -- I > would imagine it being on the order of years. [...] > Is this correct? Is there a better approach?
One thing which hasn't yet been mentioned is that file descriptors sent across Unix domain sockets and SCM_CREDENTIALS socket control messages actually provide a complete key-based authentication. Forget for one moment the oddness/uglyness of the usual user-land API and consider what the kernel actually gives you. It gives you a descriptor for kernel-held information (the underlying file struct/inode) which you can pass around between cooperating processes. SCM_CREDENTIALS allows the recipient to check the identity of the sender. Consider a daemon running with root privileges which receives requests for keys from other processes. The requesting process sends a message (which includes SCM_CREDENTIALS). On the basis of that, the daemon can decide to send the process a key: a file descriptor for a file which only a privileged process could open. The process can use that key by sending it to any other process. Ideally, you'd want the privileged daemon to be able to encode information directly in the inode so that the receiver of a key could easily check it (via fstat)--a special filesystem which just made /authfs/12345 produce an inode with inum 12345 would do the trick. Even without that, a process wanting to check a key it's been sent can send it off to the privileged daemon for verification.
In fact, with some care you can actually put together a KeyKOS-like capability-based system purely with user-land programming (basically, a gate key is a socket descriptor which is sent to the requester. The requester sends messages via the key simply by sending a message down the socket it's been passed. There's never even any need for an underlying filesystem to get involved). It's a lot more heavyweight than the real thing, but the semantics are there.
Note that all the nastiness of gc is already done in unix_gc for the access-right passing--in fact, didn't Alan get that working properly even when certain other Unices didn't gc at all :-) Further, inheritance also "just works" since they're file descriptors. A prettier user-land API is desirable and there could be a bit of extra kernel support (special filesystem or else extra scm stuff) but it's mostly there.
To sketch an implementation: write a simple pseudo-filesystem that simply maps names "12345" to inums 12345 (no actual data anywhere), a few hundred lines of code. Write a daemon which binds a Unix domain socket to /dev/keyserv and listens for requests. To get a key (equivalent to a PAG), the requester sends an SCM_CREDENTIALS message to keyserv which checks out the pid/uids/gids of the sender and, after authorising it, allocates them a fresh number (PAG=12345 say) which is kept track of locally, does fd = open("/foofs/12345") and sends back that file descriptor. That foofs is root-only: no unprivileged process can open files there. To use the key, the process uses that file descriptor as an int argument. The recipient which needs to check the key (whether kernel or user-land) just has to look at st_ino.
It does sound unwieldy (maybe just because it's a somewhat unusual way of using file descriptors--but then, the original name of the mechanism was "passing access rights") but with a bit of cleaning up, it does give all the features you need.
--Malcolm
-- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Unix Systems Programmer Oxford University Computing Services
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |