Solaris ssh pam_krb

[Nicolas Williams]

On Thu, Mar 30, 2006 at 06:58:39PM -0500, Jeffrey Hutzelman wrote:
> On Wednesday, March 29, 2006 04:12:12 PM -0600 Nicolas Williams wrote:
> >The "last two supplementary groups add up to a PAG" thing?  That won't
> >go over well :)
> 
> Actually, that's what AFS does, except it's the _first_ two groups; we 
> shift the others out of the way as needed.  It works reasonably well, 
> provided you restrict your GID space to not otherwise use the groups AFS 
> uses, and restrict your UID space to not use UID's that would conflict with 
> PAG ID's (this wasn't a problem in the days of 16-bit UID's, but it is 
> today).

Huh?  Why should UIDs not conflict with PAGs?  What am I missing?

> 
> >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).

One way to view what I'm saying is: take a single kernel-land PAG
concept and leverage it into multiple PAG types in user-land.  This
makes the system more extensible and less burdensome on the kernel.

First-class AFS-like PAGs are near trivial to implement; it gets
complicated when you have more than one use for them.

> >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...

> Anyway, what Doug is talking about is essentially keeping credentials in a 
> file whose name can be derived from the PAG ID.  But there are various 
> potential problems with this, among them the fact that users may not _want_ 
> their credentials to be used implicitly for file accesses.

What the users want their creds used for is one of the many things that
can be associated with PAGs.

Nico
--