Solaris ssh pam_krb

[Nicolas Williams]

On Mon, Apr 03, 2006 at 01:23:48PM -0400, Jeffrey Hutzelman wrote:
> On Monday, April 03, 2006 11:11:14 AM -0500 Nicolas Williams 
> <Nicolas.Williams at sun.com> wrote:
> 
> >Let's uplevel a bit.
> >
> >To me PAGs provide a useful distinction between processes in some sort
> >of session, sharing some common characteristics, one that is better than
> >environment variables in that it is easily (cheaply) observable from the
> >IPC peers.
> >
> >PAGs have, for me, at least these uses:
> >
> > - As an Identity Selection Problem tool.
> 
> Yes.
> 
> > - As a link from cred_t to user-land that can be used to "extend"
> >   cred_t.
> 
> Yes.
> 
> > - As a better point for tracking extant references to network
> >   authentication credentials than UIDs.
> 
> It's unclear to me what you mean here.

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.

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

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

I.e., because of this:

> Now, I know this has no real security value as long as it is trivial to 
> cross PAG boundaries, [...]

I'm willing to consider being able to "join PAGs one owns" (and then
dismiss this as an unnecessary complication).

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

> But again, process group separation isn't really the point.

OK, then I won't pursue that :) (But you knew I wouldn't anyways).

> The point, for AFS, is making identity selection work.

Yes.

Nico
--