Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Monday, April 03, 2006 12:56:34 PM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> That I'd rather count references to network credentials from sessions
> than from processes that might have done a seteuid() to temporarily be
> like you.  But maybe this is wrong anyways.

I guess I'm not sure what you mean by "references here".  PAG's are 
intended as a better way to select which credentials to use than looking at 
the UID, since UID's have rather narrow meaning and a user can't just 
decide he wants a new one for this session. :-)

But if you're talking about reference counting on credentials, then what 
you do depends on your model.  If you want to tie credentials to an open 
file, you need to refcount based on the file, not the UID or PAG.  OTOH, if 
you do what AFS does, which is "use whatever credentials you have at the 
time of the access", then you don't need that granularity of refcounting. 
Of course, that may produce surprising results if, for example, you pass a 
file descriptor to an unrelated process expecting to be lending your access 
rights to the file to the other process.  But it works OK for us.

Incidentally, AFS refcounts credentials, but only with regards to "active" 
use, like establishing a new connection (actually, just for creating the 
new connection.  The "security object" which contains the ticket has its 
own refcounting that the RPC layer does).  On most platforms we couldn't 
get notified on every process creation or exit even if we wanted to, and 
the OS doesn't know about our PAG's so it can't tell us when a PAG is no 
longer in use.  So, we can't refcount credentials, and instead we do a 
periodic mark-and-sweep, destroying any credentials belonging to a PAG 
which no longer contains any processes.  The PAG itself has no associated 
data structure; it's just a number.



>> > PAGs, like group memberships, do not, IMO, make a good access control
>> > on process tracing, and they are orthogonal to [local] filesystem
>> > access controls.  It would be rather surprising if one could not
>> > trace/debug one's processes from different login sessions.
>>
>> It would not be surprising if that's what you were expecting.
>
> Noone expects the Spanish Inquisition today...

:-)



>>                                                                But let's
>> leave the issue of paranoid people aside for a moment, on concentrate on
>> PAG's as an identity selection mechanism.  You're right; that's
>> essentially  how they are used in AFS today, though in a roundabout way.
>> Essentially,  we use PAG's to separate management and use of credentials
>> between  sessions.  So a user can have multiple sessions with different
>> PAG's, and  they don't interfere with each other.  He can create a new
>> PAG and set  credentials for a different identity, and processes in the
>> new PAG get the  new identity while processes in the old PAG get the old
>> one.
>>
>> 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.

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.  If you have multi-app PAG's, then it gets harder.  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.



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



> 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. 
But I also suspect there are people who would think this was a great 
badness for AFS PAG's.  I suppose it wouldn't be all that hard to allow 
PAG-joining to be disabled on a system-wide basis.




>
>>                       but the people who are really paranoid will do
>> something about it, perhaps by disabling tracing altogether (along with
>> dtrace, and the ability to load kernel modules or touch kernel memory in
>> any way, etc, etc, etc).
>>
>> 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.

-- Jeff