This section covers how file system security contexts are defined and
stored.
SELinux stores file security labels in xattrs. For more information about xattrs, read the manual pages for
attr(5), getfattr(1), and
setfattr(1). Xattrs are stored as name-value property
pairs associated with files. SELinux uses the
security.selinux attribute. The xattrs can be
stored with files on a disk or in memory with pseudo file systems.
Currently, most file system types support the API for xattr, which allows for
retrieving attribute information with getxattr(2).
Some non-persistent objects can be controlled through the API. The
pseudo-tty system controlled through /dev/pts is
manipulated through setxattr(2), enabling programs such
as sshd to change the context of a tty device.
Information about the tty is exported and available through
getxattr(2). However, libselinux
provides a more useful set of functions layered on top of the xattr API,
such as getfilecon(3),
setfilecon(3), and
setfscreatecon(3).
 | Tip |
|---|
| | It is recommended to use libselinux when managing
file attributes in SELinux programmatically.
|
There are two approaches to take for storing file security labels on a
file system, such as ext2 or ext3. One approach is to label every file
system object (all files) with an individual security attribute. Once these labels are on the file system, the xattrs become
authoritative for holding the state of security labels on the system.
The other option is to label the entire file system with a single security
attribute. This is called genfs labeling. One
example of this is with ISO9660 file systems, which are used for CD-ROMs
and .iso files. This example from
$SELINUX_SRC/genfs_contexts defines the context for
every file on an ISO9660 file system.
genfscon iso9660 / system_u:object_r:iso9660_t |
The file genfs_contexts has labels to associate with
the most common mounted file systems that do not support xattrs.
You can set the context at the time of mounting the file system with the
option -o
context=<user>:<role>:<type>.
A complete list of file system types can be found at
$SELINUX_SRC/types/file.te. This option is also
known as mountpoint labeling and is new in the
2.6.x kernel. Mountpoint labeling occurs in the kernel memory only,
the labels are not written to disk. This example overrides the setting in
genfs_contexts that would normally mount the file
system as nfs_t:
mount -t nfs -o context=user_u:object_r:user_home_t \
<hostname>:/shares/homes/ /home/ |
The -o context= option is useful when mounting file
systems that do not support extended attributes, such as a floppy or hard
disk formatted with VFAT, or systems that are not normally running under
SELinux, such as an ext3 formatted disk from a non-SELinux workstation. You
can also use -o context= on file systems you do not trust,
such as a floppy. It also helps in compatibility with xattr-supporting
file systems on earlier 2.4.<x> kernel versions.
Even where xattrs are supported, you can save time not having to label
every file by assigning the entire disk one security context.
Two other options are -o fscontext= and -o
defcontext=, both of which are mutually exclusive of the
context option. This means you can use
fscontext and defcontext with each
other, but neither can be used with context.
The fscontext option works for all file systems,
regardless of their xattr support. The fscontext option
sets the overarching file system label to a specific security context.
This file system label is separate from the individual labels on the
files. It represents the entire file system for certain kinds of
permission checks, such as during mount or file creation. Individual file
labels are still obtained from the xattrs on the files themselves. The
context option actually sets the aggregate context that
fscontext provides, in addition to supplying the same
label for individual files.
You can set the default security context for unlabeled files using
defcontext. This overrides the value set for unlabeled
files in the policy and requires a file system that supports xattr
labeling. This example might be for a shared volume that gets file drops
of security quarantined code, so the dropped files are labeled as being
unsafe and can be controlled specially by policy:
mount -t ext3 defcontext=user_u:object_r:insecure_t \
/shares/quarantined |
This all works because SELinux acts as a transparent layer for the mounted
file system. After parsing the security options, SELinux only passes normal
file system specific code to the mounted file system. SELinux is able to
seamlessly handle the text name-value pairs that most file systems use for
mount options. File systems with binary mount option data, such as NFS
and SMBFS, need to be handled as special cases. Currently, NFSv3 is the
only one supported.
SELinux uses LSM hooks in the kernel in key locations, where they
interject access vector decisions. For example, there is a hook just
prior to a file being read by a user, where SELinux steps from the normal
kernel workflow to request the AVC decision. This mainly occurs between
a subject (a process such as less) and an object (a
file such as /etc/ssh/sshd_config) for a specific
permission need (such as read).
Based on the result read back from the AVC, the hook either continues
the workflow or returns EACCES, that is,
Permission denied.
The way SELinux implements its label in the xattr is different from
other labeling schemes. SELinux stores its labels in human-readable
strings. This provides a meaningful label with the file that can help
in backup, restoration, and moving files between systems. Standard
attributes do not provide a label that has continuous meaning for the
file.
In this example under the targeted policy, the policy does not specify
anything about files created by unconfined_t in the
directory /tmp, so the files inherit the context
from the parent directory:
In this example under a different policy, the policy explicitly states
that files created by user_t in
/tmp have a type of
user_tmp_t:
This finer grained control is implemented via policy using the
tmp_domain() macro, which defines a
temporary type per domain. In this macro, the variable
$1_tmp_t is expanded by substituting
the subject's type base, so that user_t
creates files with a type of
user_tmp_t.
Having separate types for /tmp/ protects a domain's
temporary files against tampering or disclosure by other domains. It
also protects against misdirection through a malicious symlink. In the
targeted policy, the confined daemons have separate types for their
temporary files, keeping those daemons from interfering with other
/tmp/ files.
A privileged application can override any stated labeling rule by
writing a security context to
/proc/self/attr/fscreate using
setfscreatecon(3). This action must still be allowed
by policy. The context is then used to label the next newly created
file object, and the fscreate is automatically
reset after the next execve or through
setfscreatecon(NULL). This ensures that a program
starts in a known state without having to be concerned what context was
left by the previous program in
/proc/self/attr/fscreate.
