lkml.org 
[lkml]   [1998]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PROPOSAL: Process Authentication Groups (PAGs) (fwd)
Date
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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.064 / U:23.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site