Process Authentication Groups (PAGs)

Jim Dennis (jimd@starshine.org)
Wed, 25 Feb 1998 08:55:43 -0800

> From: Peter Braam <braam@cs.cmu.edu>
> Process Authentication Groups
>
> Coda as well as other system services want to implement a stricter
> form of protection and authentication. Unix authorizes processes
> based on their uid -- the uid defines a partition of the set of
> processes. Coda finds this partition into protection groups based on
> uid too coarse; the sets of processes it wants to authorize should be
> smaller.
>
> For example smbfs and ncpfs need subsets of processes to allow more
> than one authenticated session to an NT or Novel server, much like
> Coda. Another example, is that root is not to be trusted lightly but
> can change its uid easily -- systems based on the Kerberos model don't
> like this. A further worry arises when telnetd is serving two
> sessions for the same uid, it is good practice to ask each of these
> sessions to authenticate.

This is all very interesting -- however I have a
question...

Is there a way that we could add a slightly more generalized
interface for processes to be associated with a list of
"capabilities" (* a la KeyKOS, EROS, et al) -- and then use
that interface to provide PAG's?

* (for more info on these look at www.starshine.org/jim/os/)

The need for authentication mechanisms that are independent
of process uid (euid, fsuid, gid, etc) is more widespread
than just Coda -- and it would be a shame for each application
(protocol) that needed it to implement different kernel
level changes to provide essentially identical features
(capabilities).

I've heard some pretty convincing arguments for a
capabilities model over ACL's. The best I've read is:

http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html

Unfortunately, in this regard, I'm just an armchair coach.
However, I'd really like to know if there's any way we could
provide a set of "capabilities" extensions to Linux and
thereby reduce our dependence on the all-powerful and
absolutely corruptable 'root'.

(I suspect that it we'd have to build a hybrid between
Unix/Linux permissions (identity based) and the capabilities
model -- perhaps by having a "flag" in the uarea that effectively
tells the kernel and vfs code to check the process' "captable."
This would also imply that we'd have some changes that would
allow us to create and bind capabilities to files and processes
-- although we could limit it to "just" files if we require
/proc support to use this subsystem).

Ultimately I suspect that a capabilities model would be
far easier to implement than ACL's or the proposed "privs"
(Orange book) features.

If the list objects to a thread on this topic, I'll be happy
to take it offline and form a discussion group on it. Detractors
(with substantive objections!) are welcome.

--
Jim Dennis  (800) 938-4078		consulting@starshine.org
Proprietor, Starshine Technical Services:  http://www.starshine.org
        PGP  1024/2ABF03B1 Jim Dennis <jim@starshine.org>
        Key fingerprint =  2524E3FEF0922A84  A27BDEDB38EBB95A 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu