Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Thursday, March 30, 2006 06:08:10 PM -0600 Nicolas Williams 
<Nicolas.Williams at Sun.COM> wrote:

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

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.

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

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


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

-- Jeff