[redhat-lspp] New pam src rpm with namespace

[Russell Coker]

On Fri, 2006-02-17 at 10:42 -0500, Janak Desai wrote:
> >We could have sshd execute a binary (with an appropriate
> >domain_auto_trans()) that will call unshare() and then launch the
> > user session.  The binary in question could take a parameter to
> > specify the context of the session, it would then relabel the
> > controlling terminal, set the execcon for executing the shell, and
> > call unshare().
> >
> >As we already have SE Linux and audit patches in sshd I think there's
> > a strong precedent for this type of thing.  It would significantly
> >decrease the level of system access granted to sshd (removing access
> > to relabel ttys among other things).
> >
> >If this is considered a reasonable idea I'll write the patch for
> > sshd.
>
> I am not too familier with sshd but the approach seems reasonable to
> me.
> 
> Just to double check ... with this, the pam session management hooks 
> will move to this new binary, correct? 

Yes.  That's the one area of concern with this idea, that PAM may
somehow not work correctly when a different program does session.  PAM
itself by design should be fine, but as for all the PAM modules...  I'll
have to just write the code, get it tested on a bunch of machines, and
see how it goes.  If a variety of test cases don't show any unforseen
bugs then we can assume that it's going to work in most cases.

The up-side of this is that sshd is already complex and may have hit the
potential trouble areas already.

On Fri, 2006-02-17 at 10:58 -0500, Stephen Smalley wrote:
> Yes, if he can cleanly separate out not only the unshare/mount
> processing but also the user session creation (since that has to occur
> as a child of the process that unshare'd).  Not sure how
> straightforward that will be to do and maintain as a patch. 

If we are to maintain it separately then it would be a major PITA.  If
we can get it supported upstream then it shouldn't be a big deal.
Incidentally one of the guys who's involved with OpenSSH development
suggested to me that there's a reasonable chance of getting the SE Linux
patches accepted into the portable tree.  If we can get the code for
this feature working in the best possible manner and provide some
security benefits for non-SE systems then maybe we can get it included
as well.