using tmpfs for /tmp and selinux

[dragoran]

Stephen Smalley wrote:

>On Fri, 2005-03-25 at 12:56 -0500, Bill Nottingham wrote:
>  
>
>>Stephen Smalley (sds at tycho.nsa.gov) said: 
>>    
>>
>>>>in which file should I add this?
>>>>        
>>>>
>>>After further discussion on selinux list, it looks like Dan is going to
>>>take a different approach and not use a fscontext= or context= mount.
>>>Instead, he is just adding a 'restorecon /tmp' line
>>>to /etc/rc.d/rc.sysinit so that it will get relabeled to tmp_t at that
>>>time, and Dan recently added the following to the policy:
>>>	allow tmpfile tmpfs_t:filesystem associate;
>>>      
>>>
>>A question: why don't mounts normally inherit the context of the
>>directory where they're mounted in cases like these?
>>    
>>
>
>You would need rather specialized handling of tmpfs in the kernel for
>that, since:
>1) for conventional filesystems, you get the context from the on-disk
>xattr, not from the mount point,
>2) for pseudo filesystems like /proc that don't create a separate
>instance per mount, you could have multiple mounts at different points,
>but you can only have one security context assigned.
>
>tmpfs is unusual since it creates an instance per mount.
>
>Neither the LSM hook nor the kernel function which calls it that
>performs setup of the superblock and root inode doesn't even have the
>mount point available to them; you'd have to use a hook in graft_tree or
>attach_mnt.  
>
>  
>
it still does not work with the restorecon /tmp line and the policy 
changes....
same avcs...