Home ›

Kernel Korner - Filesystem Labeling in SELinux

Issue 126

From Issue #126
October 2004

Oct 01, 2004  By James Morris
 in
SELinux needs to store extra security information about each file, and Linux makes it possible with extended attributes.
Future Work

Although it is possible to assign security context labels to NFS mounted filesystems, they operate only locally for access control decisions within the kernel. No labels are transmitted across the network with files. Work has been advancing in this area, with SELinux-specific modifications being made to the NFSv2/v3 protocols and code. Further down the track, NFSv4 integration is expected to involve labeling over the wire by way of named attributes, which are part of the more extensible NFSv4 specification. This would allow both the NFS client and server to implement SELinux security for networked files. Support for other networked filesystems also would be useful, as would interoperability with Trusted BSD's SELinux port.

Backup and Restoration

One of the many tasks that change for system administrators using SELinux is backup and restoration. When creating an archive, how will the security context labels be preserved within the archive? The answer is to use the highly flexible star(1) utility, which has extended attribute support.

To manipulate archives with security context labels, use the xattr option. When creating archives, you also need to specify the exustar format. For example: 

$ star -xattr -H=exustar -c -f cups-log.star /var/log/cups

creates an archive of the /var/log/cups directory, retaining security context labels on the files.

To extract, simply use the xattr option: 

$ star -xattr -x -f cups-log.star
$ ls -Z var/log/cups/
-rw-r--r--+ root     sys      system_u:object_r:cupsd_log_t
error_log
-rw-r--r--+ root     sys      system_u:object_r:cupsd_log_t
error_log.1

As you can see, the security context labels have been preserved.

Resources for this article: /article/7689.

James Morris (jmorris@redhat.com) is a kernel hacker from Sydney, Australia, currently working for Red Hat in Boston. He is a kernel maintainer of SELinux, Networking and the Crypto API; an LSM developer and an Emeritus Netfilter Core Team member.

______________________

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
Submitted by Neville George (not verified) on Mon, 07/17/2006 - 09:36.

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
Submitted by Anonymous on Fri, 10/08/2004 - 02:00.

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

Re: Filesystem Labeling in SELinux

Anonymous's picture
Submitted by Anonymous on Thu, 10/14/2004 - 02:00.

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
Submitted by Anonymous on Sun, 10/10/2004 - 02:00.

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)

Webcast
More Resources
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers

Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions