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@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
