Please find my project description for the "session" (now PAG) and PAM
projects.  I will want to submit an edited version of the PAG discussion
to linux-kernel and Linus to see if we can mainstream this.  I welcome
comments.

- peter -



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.  Kerberos
based software generally find this partition into protection groups based
on uid too weak; the sets of processes it wants to authorize should be
smaller. 

For example, root is not to be trusted lightly but can change its uid
easily.  A second worry arises when telnetd is serving two sessions for
the same uid, Coda (or something like it) finds it necessary to ask each
of these sessions to authenticate. 

The smaller group of processes for which authentication should give
access is called a PAG, a process authentication group.  Hopefully
it is correctly described by the following:
   - Every process should belong to a pag. 
   - Pag's are inherited by fork
   - at boottime init has a zero pag
   - the setuid system call causes the process to continue its life in a
     new PAG, but setuid(SAVED_IDS) restores the PAG.  
   - when a process executes a login related operation (preferrably
     through a PAM module) this login process would execute a "setpag"
     system call which places the process in a new PAG.  
   - any process can execute setpag and thereby leave an
     authentication group of which is was a member
   - the kernel can return a list of PAG's in use (a la "ps") so that
     processes holding resources indexed by PAGs can garbage collect 
     resources for PAGS that have gone away.  This list will include
     the pags found under "SAVED_IDS". 
    
PAG's are different from process groups and session groups.  These
change more often and are meant for job control.  PAGs are totally
independent of Coda and require a system call "setpag" to join a new PAG
and a facility to list all PAGs known to the system. The could be
implemented as a 32 bit integer in the process structure.

How would Coda use PAGS?
------------------------

When a system call reaches the Coda kernel code, Coda queries Venus
for access by giving it the PAG as part of the Coda credentials of the
process.  Venus checks if it has a token for this pag and bases access
on this.  To get a token a process in the same PAG would use the
"clog" (Coda login) program.  This negotiates a session key with the
auth server (perhaps using Kerberos) and asks the kernel to pass Venus
the key and PAG. 

Related issues
--------------

A) session keys for root

There are a few interesting issues which relate to PAGS.  Since PAGS
are inherited by fork, it would be very dangerous for a root process
to have a session key.  Imagine that root has a session key and starts
a deamon process.  The deamon process would inherit the permissions
root has through it's PAG and session key and possibly pass such
permissions to any user process requesting service from the daemon. 

In contrast with this, it is highly desirable that root can start
processes which have session keys: however we don't want to give the
current PAG those session keys since that could be risky.  We propose
the following solution:

1) clog will not acquire token for the root user without a further
argument. 
2) clog can be given a "-e" (for execute) flag. If one were to
execute:
   clog braam -e program
Clog would:
   fork
   in the child:
      setpag
      get a session key
      exec(program)

If roots wants a Coda authenticated shell with a key for user moose she
would execute:
   clog moose -e bash

B) weaker authentication for special programs

Imagine that we are running an NFS server on machine A, and that A is
a coda client. We want this nfs server to export /coda to machine B,
which is NOT a Coda client.

We assume that the nfs server is well behaved and changes its fsuid to
that of the user on behalf of which it is servicing a request.

To make this useful we would want a user U on B to telnet to A and
create a "sloppy" session key there with "clog -s U".  A session key
would be given to Venus with a sloppy flag which enables the
following:

When Venus decides access permissions to serve a request coming from
the NFS server, it fails to find a PAG key for the PAG passed by the
NFS server.  It continues searching for a sloppy key matching the
fsuid of the NFS server and grants permissions based on that.

PAG project
----------- 

You should look at the process structure in the Linux (2.1) kernel.
Add a PAG field.  Write a setpag system call which assigns a new PAG
(just take an ever increasing integer -- for SMP safeness get a lock
before you increase the value). 

Make sure that setuid, setfsuid etc. change the PAG of the process as
above. 

Build the PAG into the CodaCred structure (replace the session
id). Look in linux/include/linux/coda.h and linux/fs/coda/ and search
for "cred and CodaCred".  Modify the process utilities like "ps" to
get a list of PAGs which are in use.

Finally you'll have to modify Venus to take this into account, we'll
do that later.

I will be contacting Linus Torvalds -- after some further review by
friends -- to see if he will "buy" our PAGs.  Perhaps this will lead
to some new thoughts.  Your stuff might end up in the kernel!


PAM project
-----------

As you have probably gathered this is closely related to the PAG
story.  We want two PAM modules -- one which does a setpag whenever a
process logs in (be it from the terminal, through telnet, su or ssh).
All of these can hopefully call the same PAM module. You can build
this entire module and plug in the setpag call when your colleagues
above have constructed it. 

The other PAM module tries to acquire Coda tokes when you log in: this
module MUST run after the setpag call has been made.  It might prompt
you for a Coda username and Coda password (after it fails to use the
previously entered username and password perhaps). This module would
be very similar to the clog program in the coda sources: look at
coda-src/login/clog.c.

Documentation about PAM can be found in
/usr/doc/pam-???/html/index.html
on your Linux machine.  I know many of the PAM people personally, but
I am not really an expert.

You should unpack the sources to PAM from the RedHat src.rpm and try
to understand some of the modules, and then mimic that.

I think this will be a lot of fun and the end effect would be totally
smooth Coda authentication!


Good luck.  Contact me for help if you need any.

- Peter -