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
security.selinux="root:object_r:sysadm_tmp_t\000"

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
root:staff_r:staff_t
$ 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.

______________________

Comments

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)

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState