Solaris ssh pam_krb

[Jeffrey Hutzelman]

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:
>> >> 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" ;) :]

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.


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

It gets harder (a little) because I have to actually look up the 
association.  That's not such a big deal, but...



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

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

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

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.



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




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

So do I.  And from what I've heard, the linux-kernel folks are not too 
happy about the current model, and would like to see it cleaned up.  As I 
understand it, the hooks that exist are the ones that were needed to 
provide just enough of a plugin-like interface to support SELinux.  So its 
not "broken", but it's also not as fully general is it probably should be. 
Anyway, the point is I can see how it could be done.

-- Jeff