Solaris ssh pam_krb

[Nicolas Williams]

On Mon, Apr 03, 2006 at 04:43:07PM -0400, Jeffrey Hutzelman wrote:
> On Monday, April 03, 2006 02:01:21 PM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> >On Mon, Apr 03, 2006 at 02:27:36PM -0400, Jeffrey Hutzelman wrote:
> >
> >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" ;) :]
> 
> Fine.  It's really just about making identity selection work in a sane way. 
> The idea is that if I start a new PAG, and get reduced or no credentials in 
> that PAG, then ordinary file accesses actually fail when they're supposed 
> to, rather than randomly succeeded.

Yay!  :-)

> >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 :)
> 
> No, of course not.  Actually, that's part of my point.  We avoid doing that 
> by caching established connections and indexing them by PAG, and we avoid 
> _using_ even the cached connection on every op by also caching metadata, 
> file contents, and access rights.  But if mapping the in-kernel PAG to the 
> identifier AFS actually uses requires an upcall, then I have to do the 
> upcall on every vnode and file op, because that's pretty much how often I 
> have to examine cached access rights (actually, it's not quite _that_ bad, 
> but it's close).

Ah, OK, I get it.  *This* is a kernel-side application of PAGs, yes.

But:

 - it doesn't necessarily have to be distinguished as an "application"
   as the other examples of multi-app PAG consumers do (see below)

 - you only need to upcall when a PAG->connection cache lookup misses

The only question I have then is: how to deal with new PAGs that are
intended to share their predecessors' AFS connections/credentials?

And I think the answer would either be: add an AFS-specific syscall to
establish the new_PAG->old_connection association or bite the bullet and
re-authenticate using the PAG->credentials association kept in
user-land.

I expect this sort of event to be rare.  How often do users setpag(2)?

> I'm beginning to think that maybe there is some unstated assumption here, 
> and we are talking past each other.  In your user-mode multi-app PAG world, 
> what would you have me do to find the cached access rights that apply to a 
> process?  Maybe your answer to this will uncover the disconnect.

Yes, you've identified the disconnect.  But I think there's an answer
(see above).

> >>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.
> 
> It's complicated, in part because different people have different 
> expectations.  Step out of the world of perfect security for a moment, and 
> consider the real world.  In the real world, there are people who assume 
> that because we explicitly don't provide an interface for PAG-joining, you 
> can't do it.  Some of those people are blissfully unaware that there are 
> ways to do it anyway.  Others know full well what they're getting into, and 
> consider it a problem to eventually work around.

Sorry, but I think those users will be as blissfully unaware of the one
thing (that PAGs aren't for strict separation) as of the other (that
'lo, you can "join" existing PAGs).

> Personally, I happen to think that being able to join your own existing 
> PAG's would be fine.  But I _know_ there are AFS-using sites out there that 
> feel differently.

Too bad.  They're trusting PAGs more than they should.  If they really
need a session separation feature then they need trusted OS labelling.

> >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.")
> 
> Hm, so you don't get to arbitrarily change your PAG, but you do get to set 
> existing associations.  That's interesting, because it could potentially 
> allow each application to decide whether its ID's can be joined.  That 
> might well satisfy the people who want to use PAG's for process separation.

Exactly!  :)

Nico
--