Solaris ssh pam_krb

[Nicolas Williams]

On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
> >>Now, the issue is that when you're talking about a caching distributed
> >>filesystem, your identity affects not only what credentials are used to
> >>establish connections to fileservers on your behalf, but also what you
> >>are  allowed to do with cached data and connections.  For example...
> >
> >Yes, clearly, but this doesn't make PAGs a process group separation
> >feature *locally*.  On the wire your PAGs look as though they were
> >different identities; locally they are not.
> 
> Sure.  But it turns out to be incredibly useful to have "weak" separation, 
> in which you have to go to some effort to use an identity other than the 
> one associated with your own PAG.  When you involve human users or complex 
> software build processes, the principle of least privilege becomes fairly 
> important.

I won't insist on having it both ways, and I wish you didn't either :)

Since you've agreed that PAGs are not a session separation feature I'll
just put you firmly in that column and ignore any further protestations
that PAGs are a form of "weak separation" ;) :]

> My point is that in order to make this work right, the (kernel-mode) cache 
> manager must be able to find out what "AFS PAG" a process belongs to.  If 
> you have simple PAG's, then we make "AFS PAG's" congruent to those and 
> we're done.

Sure.

>              If you have multi-app PAG's, then it gets harder.

How?  A little bit of IPC to talk to the right daemon that keeps the
PAG->network-authentication-credential association doesn't seem "hard"
to me...

>                                                                 I just 
> don't want it to be so hard that I have to do at least one upcall to 
> user-mode for every vnode or file op on a file in AFS.

Oh no, not "for every vnode or file op" -- for every authentication
attempt.  Surely AFS does not do an AP exchange "for every vnode or file
op," right?  Right?!

Please tell me that it doesn't...  If not I may have to laugh at AFS :)

> >>Now, the thing that makes PAG's more than just identity selection is
> >>that  you can't arbitrarily select a PAG -- you can use the one you
> >>have, or ask  for a new (empty) one, but you can't pick up one
> >>arbitrarily and use it.
> >
> >It's trivial to implement this, but we could also allow one to join
> >arbitrary PAGs that one also owns (i.e., label PAGs with the euid [or
> >ruid?] of the process that creates them and let the same user's other
> >processes join any PAGs that user owns).
> 
> Yes, you could do that.  Those wouldn't be the same semantics as AFS, but 
> that's not necessarily a problem.  It _would_ be very similar to the 
> semantics of Kerberos file ccaches, which can also be useful.

Since you agree that PAGs are not a session separation feature I don't
see how the semantics of this "join PAGs I own" feature would be
incompatible with the semantics of AFS PAGs, but an extension.

> >I'm willing to consider being able to "join PAGs one owns" (and then
> >dismiss this as an unnecessary complication).
> 
> I'm not sure what to think about this.  Personally, I make fairly heavy use 
> of the idea that I can pick up an existing ccache owned by me and use it. 

I should correct myself here -- the right way to implement "join PAGs
one owns" in the scheme I've proposed is to find the associations of the
PAG you want to join, join new PAG instead, and then establish all those
associations for the new PAG.  (To keep continuity I'd make associations
to PID before joining a new PAG -- "make before break.")

> >>Interestinly, while PAG's don't directly provide process group separate,
> >>it  occurs to me that given the ability for in-kernel code to determine
> >>a  process's PAG, they could be used to _implement_ stronger session
> >>separation.  I don't know enough about the internals of Solaris, but I
> >>bet  I could write a security module for Linux that did exactly this,
> >>using AFS  PAG's.
> >
> >A module?  On Solaris you'd have to change a variety of existing
> >functions, like secpolicy*().  Would it be much easier to do this in
> >Linux?
> 
> Yes, to some extent.  Linux has a pluggable security module framework, in 
> which the registered security module is called in various places to 
> determine if an operation is allowed, what its effects will be, and/or 
> whether there are side-effects.  I'm afraid the placement of such hooks is 
> a little haphazard and probably sparser than it should be, but I believe 
> there are enough that I could prevent processes in different PAG's from 
> tracing each other.

Well, good luck.  I think one should be rigorous, not "haphazard" in
designing a kernel-level extensible authorization scheme.  I've not
looked at these hooks in Linux, so I'll take your word as far as their
placement.

Nico
--