Re: user guide drafts: "Mounting File Systems"

[Murray McAllister <mmcallis@redhat.com>]

Stephen Smalley wrote:
> On Thu, 2008-10-16 at 11:43 +1000, Murray McAllister wrote:
>> Mounting File Systems
> 
> I'd start first by describing the common behavior, e.g.:
> 
> By default, when a filesystem that supports extended attributes is
> mounted, the security context for each file is obtained from the
> "security.selinux" extended attribute of the file.  Files in filesystems
> that do not support extended attributes are assigned a single default
> security context from the policy configuration based on filesystem type.
> 
> Then you can continue with:
> 
>> Use the mount -o context command to override existing extended 
>> attributes.
> 
> or to specify a different default security context for filesystems that
> do not support extended attributes.
> 
>>  This is useful if you do not trust a file system to supply 
>> the correct attributes, for example, removable media used in multiple 
>> systems. The mount -o context command can also be used to support 
>> labeling for file systems that do not support extended attributes, such 
>> as File Allocation Table (FAT) file systems.
> 
> Or NFS filesystems.
> 
>>  The context specified with 
>> mount -o context is not written to disk: the original contexts are 
>> preserved, and are seen when mounting without a context option.
> 
> if there were any extended attributes on the disk in the first place.
> Which typically won't be the case when using context mounts.
All of the above sounds good.
> 
>> Temporary Mount Context Changes
> 
> I wouldn't call them "temporary".  We have called it mountpoint labeling
> or context mounts in the past, and they can be "persistent" in the sense
> of putting it in your fstab and having it always applied on every mount.
> They just aren't stored on the media.
Changed to "Context Mounts".
> 
>> As the Linux root user, use the mount -o 
>> context=SELinux_user:role:type:level command to mount file systems with 
>> the specified context, overriding existing contexts if they exist. 
>> Context changes are not written to disk. In the following example, when 
>> /dev/sda1 is mounted, all files on that file system are labeled with the 
>> system_u:object_r:httpd_sys_content_t:s0 context. This example can be 
>> used to share FAT file systems (or other file systems) via the Apache 
>> HTTP server:
>>
>> # mount -o context="system_u:object_r:httpd_sys_content_t:s0" /dev/sda1 
>> /mount/point
> 
> I'd tend to give example of mounting removable devices (floppies,
> CD/DVDs, USB drives) or NFS filesystems, as that is generally when one
> would use a context mount.
I have used an NFS example.
>> Newly-created files and directories on this file system appear to have 
>> the SELinux context specified with -o context; however, since context 
>> changes are not written to disk for these situations, context changes 
>> are lost when the file system is unmounted. If such a file system is not 
>> labeled, or does support extended attributes, it stays in that state 
>> after being unmounted.
>>
>> Type Enforcement is the main permission control used in SELinux targeted 
>> policy. For the most part, SELinux users and roles can be ignored, so, 
>> when overriding the SELinux context with -o context, use the SELinux 
>> system_u user and object_r role, and concentrate on the type. If you are 
>> not using the MLS policy or multi-category security, use the s0 level.
>>
>> <note>
>> When a file system is mounted with a context option, context changes (by 
>> users and processes) are prohibited. For example, running chcon on a 
>> file system mounted with a context option results in a Operation not 
>> supported error.
>> </note>
>>
>> Changing the Default Context
>>
>> As the Linux root user, use the mount -o 
>> defcontext=SELinux_user:role:type:level command to change "the default 
>> security context for unlabeled files"[1]. The defcontext option requires 
>> a file system that supports extended attributes, since context context
> 
> double word
> 
>> changes for newly-created files that would otherwise be labeled with the 
>> file_t type are written to disk.
> 
> What?  The point is that defcontext= is meaningless if the filesystem
> doesn't support extended attributes because it means "treat files that
> lack an extended attribute as if they had this context".  But the
> defcontext itself is not stored on disk.
I was trying to explain (tested on Fedora Rawhide):

1. create a logical volume. mkfs.ext3 [new logical volume].
3. create a /test/ directory. mount the logical volume to /test/
5. create /test/file. This file uses the file_t type.
6. unmount.
7. mount with defcontext option. create /test/file2. File2 uses type 
specified with defcontext. "file" is still labeled with the file_t type.
9. remount with no context option. file2 still has the type specified 
with previous defcontext option.

Is this the expected behavior?
> 
>>  The file_t type is used for files 
>> (stored on a file system that supports extended attributes) that do not 
>> have an SELinux context. This type should not exist on correctly-labeled 
>> file systems.
>>
>> The following example changes the default context to 
>> system_u:object_r:httpd_sys_content_t:s0:
>>
>> # mount -o defcontext="system_u:object_r:httpd_sys_content_t:s0" 
>> /dev/sda1 /mount/point
> 
> Again, I would tend to use an example that is more realistic, like a
> removable device or NFS filesystem.
> 
>> In this example, if the file system on /dev/sda1 isn't labeled 
>> correctly, or isn't labeled at all, newly-created files are labeled with 
>> httpd_sys_content_t type, rather than the file_t type. If a file that 
>> would otherwise be labeled with the file_t type is created on this file 
>> system, it keeps the httpd_sys_content_t type, even when the file system 
>> is mounted without a context option.
>>
>> [1] Morris, James. "Filesystem Labeling in SELinux". Published 1 October 
>> 2004. Accessed 14 October 2008: http://www.linuxjournal.com/article/7426.
>>
>> Multiple NFS Mounts from the same Export
>>
>> To mount a single NFS export multiple times using a different SELinux 
>> context for each mount, use the mount -o nosharecache,context options. 
>> The context specified with with context option is not written to disk:
>>
>> # mount hostname:/export /local/mount/web -o 
>> nosharecache,context="system_u:object_r:httpd_sys_content_t:s0"
>> # mount hostname:/export /local/mount/database -o 
>> nosharecache,context="system_u:object_r:mysqld_db_t:s0"
> 
> Caveat:  Do not ever do this for overlapping mounts or you'll create a
> situation where the same file is accessible under two different security
> contexts.
Is overlapping what I have done above, or do you mean manually mounting 
an NFS export to the same directory that mounts the NFS export via 
autofs? I tried mounting via autofs, and then manually mounting with a 
context option in Rawhide. I had no errors or denials. mount showed:

localhost:/export on /misc/test type nfs 
(rw,soft,initr,sloppy,addr=127.0.0.1)

localhost:/export on /misc/test type nfs 
(rw,context="system_u:object_r:samba_share_t:s0",addr=127.0.0.1)

With both mounted, "ls -Z /misc/test" showed files using the 
samba_share_t type.
> 
>> In this example, the hostname:/export NFS export is mounted to two 
>> different directories, /local/mount/web and /local/mount/database. Files 
>> mounted on /local/mount/web are labeled with the httpd_sys_content_t 
>> type. Files mounted on /local/mount/database are labeled with the 
>> mysqld_db_t type.
>>
>> If a single system runs a MySQL® server as well as an Apache HTTP 
>> Server, and data files for both of those services are on a single NFS 
>> export, this example can be used to allow both the MySQL server and the 
>> Apache HTTP Server access to the required files, without exposing the 
>> files to other local services.
>>
>> # This is probably incorrect. I do not know a proper use cases for this.
>>
>> Note: if you attempt to mount a single NFS export multiple times with 
>> different contexts, but do not use the nosharecache option, mount fails 
>> with a mount.nfs: an incorrect mount option was specified error, and the 
>> following is logged to /var/log/messages:
>>
>> kernel: SELinux: mount invalid.  Same superblock, different security 
>> settings for (dev 0:14, type nfs)
>>
>> Further Information
>>
>> For further information about file system labeling, refer to James 
>> Morris's "Filesystem Labeling in SELinux" article: 
>> http://www.linuxjournal.com/article/7426.
> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.