Kernel Korner - Filesystem Labeling in SELinux

SELinux needs to store extra security information about each file, and Linux makes it possible with extended attributes.
EA Security Labeling

EAs can be managed manually with the getfattr(1) and setfattr(1) utilities. For example, to view the SELinux security context label of a file:

$ getfattr -n security.selinux /tmp/foo
getfattr: Removing leading '/' from absolute
path names
# file: tmp/foo

Notice the specification of the EA security namespace. A wrapper utility called getfilecon(1) is provided for use with SELinux. It saves you from having to specify the EA namespace, and it has a cleaner output.

The use of text-based labels ensures that meaningful, human-readable security attributes are stored along with the file data. These labels can be preserved or translated if the filesystem is mounted on a different system, possibly with a different security policy. A counter example is the way the owner of a file is stored as a numeric UID in the file's inode. The UID typically is mapped to a meaningful value by way of /etc/passwd; it may not have the same meaning on a different system.

For a filesystem to support SELinux security context labels, it needs EA support and a handler for the EA security namespace. Such filesystems currently include ext3, ext2, XFS and ReiserFS; the last uses an external patch. In addition, the devpts filesystem has a dummy security handler that allows EA-based access to the in-kernel labels of ptys.

So, when are files labeled? During an SELinux system installation, the setfiles(8) utility typically is used to label all of the files in filesystems that support EA security labeling. Package management tools such as RPM also may label files during installation, while system administrators often need to set security contexts manually with chcon(1) or setfilecon(1).

File Creation

When a file is created, a matching rule in the security policy typically describes how to assign a label based on the security contexts of the parent directory and the current task. Here's an example:

$ id -Z
$ ls -dZ /tmp
drwxrwxrwt+ root  root system_u:object_r:tmp_t /tmp
$ touch /tmp/hello
$ getfilecon /tmp/hello
/tmp/hello      root:object_r:staff_tmp_t

In this case, the security policy contains a rule that states files created by staff_t in a directory labeled tmp_t must be labeled with the type staff_tmp_t. If there is no explicit rule, files are labeled with the context of the parent directory.

Privileged applications can override the above-stated rule by writing a security context to /proc/self/attr/fscreate. This security context then is used to label any newly created files. The setfscreatecon(3) library function encapsulates this operation.

Unlabeled files may exist if a filesystem has not been labeled properly before use or if files are created on a filesystem when SELinux is not enabled. In case of the latter, the SELinux kernel internally assigns a default context to unlabeled files for AVC calls, but it does not attempt to relabel them on disk. To restore a security context label manually, use restorecon(8).

An fsck-like utility is being developed for managing the scenario where unlabeled files have been created. To be run on boot, this utility will ensure that all files are labeled correctly before the system enters multiuser mode.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Question about Mounting filesystem using security context

Neville George's picture

Hi.. I am an intermediate user of Linux and I am baffled with this "security context" introduction. For most of the part, I get it but when coming to mounting filesystems it is driving me crazy.

First, my man pages for mount does not mention anything about context or fscontext (I dont think this is a problem)

Second, no matter what I try I am not able to see the security context of the mounted point. The commands I issued were

=> mount -v -t ext3 -o context=system_u:object_r:mnt_t /dev/mapper/datavg-data /var/data

(This command actually worked, meaning I could not see any of the security contexts of the files under /var/data after mounting - kind of consistently inconsistent)

=> mount -v -t ext3 -o fscontext=system_u:object_r:mnt_t /dev/mapper/datavg-data /var/data

(I was able to see the security context of all the files under /var/data but an "ls -ldZ /var/data" does not show me the security context. It shows up as a blank)

The problem is really that I am trying to write/read/edit files under /var/data/somefolder and I am not able to perform this (it appears to the best of my testing that there is some relation with /var/data not having a security context). I get the error message as mentioned in your article - meaning PID error, access denied)

Question is:
- If properly mounted with security context, should "ls -ldZ /var/data" show me the security context ? I am assuming this is a dumb question and the answer is YES.
- What can I do next to get this thing to work ?

Any help at the earliest is appreciated.

Re: Filesystem Labeling in SELinux

Anonymous's picture

You don't explain how SELinux is different than standard Unix security?

Re: Filesystem Labeling in SELinux

Anonymous's picture

Is different because it implement ACLs, so you can be root in a given security context but will no be able to write any file in another security context.

This way an exploit that gives root access trought a give service, only can fake files on the service's security context, but will not be able to change other important system files (even being root).

Re: Filesystem Labeling in SELinux

Anonymous's picture

SELinux is an implementation of Mandatory Access Control (MAC).
Standard UNIX security is Discretionary Access Control (DAC). Use Google to find out more (keywords: Mandatory Access Control, Discretionary Access Control, Common Criteria, Orange Book)

One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix