[redhat-lspp] New pam src rpm with namespace

[JANAK DESAI]

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.
>>
>>/* Allow setting the domainname */
>>/* Allow setting the hostname */
>>/* Allow VM86_REQUEST_IRQ */
>>/* Allow removing semaphores */
>>/* Used instead of CAP_CHOWN to "chown" IPC message queues, semaphores
>>   and shared memory */
>>/* Allow locking/unlocking of shared memory segment */
>>/* Allow forged pids on socket credentials passing */
>>/* Allow reading non-standardized portions of pci configuration space */
>>    
>>
>
>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.
>
>Splitting sys_admin capability itself is problematic, as the capability
>bit space is nearly exhausted.  But you can certainly add further
>SELinux checks on the same code paths to provide finer-grained control.
>But there are a lot of CAP_SYS_ADMIN checks in the kernel to instrument
>in that manner.
>
>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.
>
>  
>
hmm.. if you call unshare from a helper program, it will only affect the 
namespace
of the helper program. You can move mount/umount processing to another 
program
but you still need to call unshare from the pam_namespace module.

-Janak

-Janak