danwalsh (danwalsh) wrote,

The joy of SELinux relabelling.

One common complaint about SELinux is that it takes a long time to relabel. A relabel walks all of the mounted file systems that support labelling, and compares the file context on the file to the system default, if they differ, the process will fix the label. Sadly a common misconception about SELinux is that one of the best ways to fix SELinux problems is to touch /.autorelabel; reboot. Even I have suggested this a few times.

Note: File systems that support labelling are identified by looking for the seclabel field in /proc/self/mounts. File systems mounted with a context mount do not have this field. See below.

Full relabelling of an SELinux machine should almost never be necessary, Unless you disable SELinux. And none of you would ever do that :^), permissive mode is a much better idea. Running restorecon recursively on a directory is a better and much quicker solution. But sometimes a machine could get so totally corrupted that you have to autorelabel. An admin going crazy with chcon?

Every selinux-policy update package includes a limited relabel, although sometimes this is less limited then others. The package update fixes all labels that changed in the update. The selinux-policy package compares the file context file pre install and post install and attempts to relabel the greatest common denominator, if I remember my math terms correctly. Basically if the update package sees label changes in /usr/lib64 it will run a fixfiles /usr/lib64.

I have seen emails talking about the problem of length of relabelling like the following.

John Mellor states
"if I have a few petabytes of disks attached, I do NOT want that walked under any circumstances by the relabelling process."

Daniel Thurman asks "I have several versions of root distro partitions of which I do mount via fstab, but of course only one / and /boot partition is to be defined for the version to be booted.

What I would like to know is, if I do an /.autorelabel, for one boot/root partition, does this mean that every mounted filesystem that appears in /etc/fstab also gets relabeled? If so, this is not what I want especially if other root distro partitions are being mounted for example,
say: /md/{distro1, distro2, ...}

So, How do I get around this? "

One solution suggested by Paul Howarth was to create a local policy module called otherdistros.

"I create a local policy module for this sort of thing, with a file contexts entry like this:

# Don't touch stuff here
/srv/homes(/.*)? <<none>>

So you could have:
/md/distro1(/.*)? <<none>>
/md/distro2(/.*)? <<none>>

policy_module(otherdistros, 0.0.1)

Building and installing that module should do the trick.
A simpler solution would be to execute

# semanage fcontext -a -t "<<none>>" '/md/distro?(/.*)?'

This semanage command tells the SELinux tools that the labels under '/md/distro?' have no default labels, do not try to relabel them.

Another solution, if the files you do not want relabelled exist on a different file system you can use the context mount option. Adding a /etc/fstab entry like:

/dev/VolGroup00/LogVol02 /myweb ext4 context="system_u:object_r:http_sys_content_t:s0",defaults 0 0

stops the relabel from walking down that path. It tells SELinux to treat every file on the file system as http_sys_content_t.

Note: DO NOT do this on standard directories, meaning do not label all of /usr as httpd_sys_content_t, your system will not work.

Both touch /.autorelabel;reboot and yum update selinux-policy execute the /sbin/fixfiles bash script. If someone wants to patch it to allow admins to specify directories to execlude from relabel, patches accepted.


  • Container Domains (Types)

    One of the things people have always had a hard time understanding about SELinux is around different types. In this blog, I am going to discuss…

  • Musings on Hybrid Cloud

    I work on the lowest levels of container runtimes and usually around process security. My team and I work on basically everything needed run…

  • Container Labeling

    An issue was recently raised on libpod, the github repo for Podman. "container_t isn't allowed to access container_var_lib_t" Container policy…

  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 1 comment