Solaris ssh pam_krb

[Douglas E. Engert]

While you are thinking about PAGs, how do you handle Solaris zones
with PAGs?

AIX and HPUX had a PAG field in the creds to be used with DFS.
Since DFS come out of Transarc then part of IBM and since DFS was
based on AFS, they may have gotten their kernel people to add the
field so the PAG could be used for AFS and DFS. I believe OpenAFS
uses this field on AIX today.

HP was pushing DFS at one time too, and sys/cred.h in the ucred has
    unsigned long cr_pag /* PAG for HP-DFS */
But OpenAFS appears not to use this.



Nicolas Williams wrote:

> On Fri, Mar 31, 2006 at 01:27:49PM -0500, Ken Hornstein wrote:
> 
>>>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.
>>
>>I'm curious ... why do you want a userspace daemon to be involved?  I think
>>you could simplify things by making a complete kernel-only implementation.
> 
> 
> Flexibility, kernel memory usage.
> 
> First-class AFS-like PAGs would be a cheap facility requiring no special
> caller privilege, and there's little scope for attacking the kernel -- a
> tight for loop over setpag(2) won't hurt anyone, particularly if PAGs
> are 64-bit numbers (at worst you may want to microsleep for a milisecond
> per-setpag() call.  Even if we throw in empty-PAG notifications we still
> have a small, constant size of memory consumption per-PAG, at most
> per-process (fork() many processes, have each call setpag(2)).
> 
> First-class multi-application PAGs would not be so cheap in the kernel,
> and there would have to be a finite number and registry of applications
> to prevent resource consumption attacks.  Adding applications to the
> registry would be a complication (you don't want to have to reboot for
> that) requiring privilege.
> 
> I grant that altogether it's not *that* much more complicated than the
> simple-kernel-PAG-with-multi-apps-support-in-user-land approach.  It
> seems mostly a matter of moving complexity around...
> 
> 
>>I know that gssd is userspace, but that's obviously because it would suck
>>to cram the whole Kerberos and GSS libraries into the kernel.  If it's
>>just "associate this processes tree with this cookie", then it would be
>>simpler (I think) to make the whole thing kernel-only.
> 
> 
> ...and I tend to prefer having the complexity in user-land as that's
> easier to debug and patch (rebooting vs. restarting a service).
> 
> 
>>(I am personally not worried about the API; I'm sure whatever the API ends
>>up being, it will be fine.  It's the implementation that concerns me).
> 
> 
> Do you prefer a kernel-land implementation?
> 
> Nico

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444