[redhat-lspp] New pam src rpm with namespace

Janak Desai janak at us.ibm.com
Fri Feb 17 15:42:51 UTC 2006


Russell Coker wrote:

>On Thu, 2006-02-16 at 08:32 -0500, Stephen Smalley wrote:
>  
>
>>On Thu, 2006-02-16 at 11:08 +1100, Russell Coker wrote:
>>    
>>
>>>Might it be time to split sys_admin capability?
>>>
>>>sshd by it's nature needs network access and therefore is something we
>>>want to lock down as much as possible.  sys_admin gives a heap of access
>>>and we certainly don't want to permit all that if we can avoid it.
>>>
>>>Below are the sys_admin items which don't seem to be restricted by other
>>>parts of SE Linux policy.
>>>      
>>>
>> 
>>And no doubt that is only a partial list, as people are unlikely to have
>>documented all uses of CAP_SYS_ADMIN in capability.h.
>>    
>>
>
>It's even worse than I thought then.
>
>  
>
>>Might be easier to just move the mount/umount processing from being
>>directly done by the pam_namespace module into a helper program, and run
>>that in its own domain separate from sshd and other callers.
>>    
>>
>
>Contrary to the opinion of other people here, I believe that is
>possible.
>
>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?

-Janak




More information about the redhat-lspp mailing list