Solaris ssh pam_krb

[Nicolas Williams]

On Thu, Mar 30, 2006 at 08:02:14PM -0500, Jeffrey Hutzelman wrote:
> On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams 
> <Nicolas.Williams at Sun.COM> wrote:
> >Huh?  Why should UIDs not conflict with PAGs?  What am I missing?
> 
> Because AFS identifies credentials, cached connections, and cached access 
> rights by a 32-bit number which is either a UID or a PAG.  So the 
> namespaces for those need to not overlap.  AFS uses 0x41000000.. 0x14FFFFFF 
> for PAG's, leaving the rest of the 32-bit space for UID's.

Ugh.

> >>> We need a first-class PAG-like thing.
> >>
> >>Please!  Be the first OS vendor on your block to provide them!
> >
> >Unfortunately it's a bit harder than that.
> >
> >I have lots of uses for PAGs besides tracking krb5 tix.  I don't want a
> >PAG-like item per-such use.  I want a daemon (least priv and all that)
> >that tracks PAG<->{whatever} associations.  It has to be lightweight and
> >not easily DoSed.  And this needs an API.  And it needs to allow you to
> >create a new PAG while keeping all your old associations and breaking
> >only the ones you want to break, which also means some access control
> >(euid will do).
> 
> The last is very tricky.  To get it right, code has to not actually track a 
> process's credentials (and associated cached stuff) directly by its PAG, 
> but by a per-application identifier with a many-to-one mapping between 
> PAG's and application identifiers.  Any application has to be able to add a 
> mapping from an existing PAG to one of its identifiers, if one doesn't 
> already exist.  And, applications need to be able to ask the question "is 
> this still in use?".  And the fun part - these things have to be possible 
> not only from user mode but also from the kernel.

No, the kernel doesn't need PAGs for itself -- it upcalls to daemons
that do (e.g., gssd(1M)) and which can use door_ucred(3DOOR) and friends
to find out what the caller's PAG is.

> In any event, the API is easy.  The hard part is the _user_ interface...

The user interface is easy: PAM (not quite in its present form) can
handle all logon-time issues, while programs like kinit and keylogin can
take care per-application associations in specific cases, and a generic
command can list/break any/all associations.

Yes, an event facility is needed to detroy credentials on refcount drop
to zero.

> 
> >>> The audit session ID comes close to being that, but falls short (for
> >>> one, it's 32 bits, so too small, but also audit isn't on by default,
> >>> and the model is that you don't change a process' audit session ID
> >>> ever once set).  Process contracts also come close but fall short in
> >>> that a process can be in only one process contract and SMF use of
> >>> process contracts would conflict with AFS/DCE-style use of PAGs.  We
> >>> could build PAGs as extensions to process contracts, or as yet another
> >>> process grouping mechanism (which is how PAGs look in AFS).
> >>
> >>Right; AFS PAG's are just another kind of process group.  They happen to
> >>have exactly the same inheritance semantics as supplemental groups,
> >>except  that setgroups() doesn't touch them, and any process can ask for
> >>a new one.  (In addition, AFS let's you get a new PAG and ask for your
> >>parent to be  moved into it with you; this lets 'newpag' be a program
> >>users can call from  the shell.  But this behavior is considered an evil
> >>aberration that we wish  would go away).
> >
> >In Solaris the way you'd do the "change parent's PAG" is through /proc
> >(we really need a stable, public version of the libproc API, which makes
> >/proc reall easy to use...).
> >
> >In fact, you can do the AFS hack today using /proc...
> 
> Not without privileges you can't.

Er, well, yes, but that is true even for the case where the process is
creating a new PAG with this hack -- this isn't /proc's fault but the
result of using supplementary groups to emulate first class PAGs.

Nico
--