Kernel Korner - Filesystem Labeling in SELinux

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

With NSA Security-Enhanced Linux now integrated into the 2.6 kernel and making its way into distributions, an increasing number of people likely will be installing SELinux and experimenting with it. Given this increasing user base, this article takes a closer look at filesystem labeling under SELinux. This is an intermediate-level article. Although a brief review of some SELinux concepts is provided in the next section, pointers to more detailed information can be found in the on-line Resources section. In particular, Faye Coker's introductory article [LJ, August 2003] is recommended as a starting point.

SELinux Overview: Labeling and Access Control

In SELinux, important objects, such as tasks, inodes and files are assigned a security context, a label that encapsulates the security attributes associated with an object. Under standard SELinux, this label is a colon-separated ASCII string composed of values for identity, role and type.

These labels are assigned by a kernel component called the security server, using rules loaded into the security policy database. The security context label on my workstation's /etc/shadow file is:


where system_u and object_r are generic identity and role values used for files. shadow_t is the type of the file, an attribute that determines how the file can be accessed. A process, for example, would be labeled like this:


The SELinux identity here is root, assigned by SELinux as a more permanent form of identity than the standard UNIX identity. The role is staff_r, indicating that the process has all of the permissions assigned to that role. The type assigned to the process is staff_t. For a process, the type attribute indicates how it is allowed to access objects and interact with other processes. The type attribute of a process often is referred to as a domain.

Access Control Decisions

SELinux uses these security context labels to make access control decisions between processes and objects, but how does this happen? SELinux has hooks located at strategic points within the core kernel code, such as the point where a file is about to be read by a user. These hooks allow SELinux to break out of the normal flow of the kernel to request extended access control decisions. Access control decisions usually are made between a process (for example, cat) and an object (for example, /etc/shadow) for a specific permission (read).

Decision requests are sent to the access vector cache (AVC), which passes requests through to the security server for interpretation. The security server consults the security policy database and determines a result, which is cached in the AVC and returned to the SELinux hook.

The SELinux hook then allows the flow to continue or return EACCES, depending on the decision result. Security context labels assigned to processes and objects are used to make these access control decisions.

Refer to Figure 1 for a simplified view of this process.

The following code demonstrates how security context labels are used on a real system, as seen by a user:

$ id -Z

$ cat /etc/shadow
cat: /etc/shadow: Permission denied

The audit log records the following:

avc:  denied  { read } for  pid=13653 exe=/bin/cat
name=shadow dev=hda6 ino=1361441 scontext=root:staff_r:staff_t
tcontext=system_u:object_r:shadow_t tclass=file

Translation: the cat program, labeled with the security context root:staff_r:staff_t, was denied permission to read a file labeled system_u:object_r:shadow_t.

SELinux knows nothing about the meaning of cat or /etc/shadow. It is concerned only with their respective security context labels, the class of the target object (in this case, it's a file) and the permission being requested.

An important aspect of SELinux design is that labels encapsulate all security attributes of an object, and they are interpreted only by the security server in the kernel and by libselinux in user space. The rest of the kernel code and user space merely pass labels around as opaque data. New security attributes can be added to labels without having to recompile applications or redesign core SELinux code.

Extended Attributes

On a typical Linux disk-based filesystem, each file is identified uniquely by an inode containing critical metadata for the file, including UNIX ownership and access control information. When the kernel references a file, its inode is read from disk into memory. A standard UNIX permission check simply uses the information present within the inode. SELinux extends standard UNIX security and uses security context labels to make extended access control decisions.

Linux implements Extended Attributes, also called EAs or xattrs. These are name/value pairs associated with files as an extension to normal inode-based attributes. EAs allow functionality to be added to filesystems in a standardized way so that interfaces to the attributes are filesystem-independent. Examples of EA functionality are access control lists (ACLs), storage of character-set metadata alongside file data and SELinux security context labeling.

EAs are stored within namespaces, allowing different classes of EAs to be managed separately. ACLs are stored in the system.posix_acl_access and system.posix_acl_default namespaces. SELinux security context labels are stored in the security.selinux namespace. See attr(5) for more information on EAs under Linux.



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)

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

Upcoming Webinar
8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot