On CentOS 7.5, Linux 3.10.0-862.3.2.el7.x86_64, I'm trying to understand how file contexts work. ls -Z, chcon and semanage seem to work as expected, but restorecon seems stubbornly silent.

For example:

$ cd
$ mkdir context
$ ls -laZ
drwxrwxr-x  liteyear liteyear ?                                context
$ chcon -v unconfined_u:object_r:user_home_t:s0 context
$ ls -laZ
drwxrwxr-x. liteyear liteyear unconfined_u:object_r:user_home_t:s0 context
$ rmdir context

All good, and semanage:

$ mkdir context
$ sudo semanage fcontext -a -t user_home_t /home/liteyear/context
$ cat /etc/selinux/targeted/contexts/files/file_contexts.local

# This file is auto-generated by libsemanage
# Do not edit directly.

/home/liteyear/context    system_u:object_r:user_home_t:s0

All good, but the restorecon route:

$ restorecon -v /home/liteyear/context
$ ls -laZ
drwxrwxr-x  liteyear liteyear ?                                context

doesn't apply the file context.

I've tried various iterations, with existing contexts, different contexts, other folders and files, and restorecon has never produced anything. There are various similar reports (eg. [CentOS] SELinux restorecon does not work) but no one seems to have confirmed there's an issue.

Is this the way restorecon is supposed to work?

  • 1
    Try "restorecon -Rv /home/liteyear/context" – Buddika Jul 19 '18 at 7:42
  • restorecon -Rv /home/liteyear/context made no difference to the outcome – Heath Raftery Jul 19 '18 at 10:02
  • Is SELinux enabled (you can check iwith sestatus)? I find it odd that file context is not applied automatically on directory creation (your first mkdir, I assume it is in your home directory). – sebasth Jul 19 '18 at 10:51
  • I did too and sure enough, sestatus says disabled. So it's silently ineffective? This all came about when I was trying to recreate /var/lib/php/session to suit nginx - it had a file context and so I set about restoring it. If you could add an answer with "because its disabled" and add why it would be disabled and whether to worry about it, I'd be happy to accept it. – Heath Raftery Jul 20 '18 at 0:59
  • As to why SELinux might have been disabled: the default configuration possibly prevented some application from working and the person who set the system up didn't to know how to configure SELinux; and to get the application working decided to disable it completely. SELinux provides additional layer of security by confining processes running on the system. Enabling SELinux would require you to configure your system, if it hasn't been done and the default policy causes issues. If you decide to enable SELinux, you should read the documentation (link in my answer) to avoid issues on first boot. – sebasth Jul 20 '18 at 16:15

On running systems with SELinux enabled, new files and directories inherit the context from parent directory or apply a context per policy rules. Example shows that no SELinux context is applied when directory is created, visible from ls -Z output as ? in Security Context column.

This suggests SELinux is not enabled on your system. When SELinux is enabled, file contexts would be automatically applied by the system.

You can check SELinux status with sestatus command.

If you wish to re-enable SELinux, you should check the documentation in advance. The system should be booted in permissive mode first to be relabeled (missing labels to be applied) and any apparent issues should be fixed before switching to enforcing mode.

SELinux requires often some configuration: you might have files in locations not included in default policy or your application might require more permissions than the default policy allows. audit2allow and audit2why are useful tools when investigating SELinux logs and often reveal wrong file labels or suggest booleans which can resolve issues.

SELinux also has permissive domains which can be used to disable SELinux for certain domains (processes) while leaving rest of the policy in enforcing mode. In permissive mode logs are generated in same way as in enforcing mode for access that would otherwise be denied. Obviously, running an application in permissive domain is practically the same as running the application SELinux disabled.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.