Red Hat Bugzilla – Bug 1260238
RFE: restorecon should say in verbose mode when it doesn't change a context due to customizable_type
Last modified: 2018-04-10 12:37:28 EDT
Description of problem: So, this afternoon, I did played with selinux sandbox, and due to me experimenting, this resulted into this: $ ls -ldZ /tmp/ drwxrwxrwt. root root unconfined_u:object_r:sandbox_file_t:s0:c446,c554 /tmp/ (I found out later in the day when openvpn failed, and it was by using -T on /tmp, me likely not doing things correctly and running it as root, etc. Bug is not about how I did stupid things by being stupid). So the easy solution to fix is restorecon: $ sudo restorecon -v /tmp $ ls -ldZ /tmp/ drwxrwxrwt. root root unconfined_u:object_r:sandbox_file_t:s0:c446,c554 /tmp/ Nope. I did checked with matchpathcon: $ matchpathcon /tmp /tmp system_u:object_r:tmp_t:s0 So let's fix by hand: ~ $ sudo chcon -v system_u:object_r:tmp_t:s0 /tmp changement du contexte de sécurité de « /tmp » and now it worked. Problem is "why restorecon silently said nothing ?" Version-Release number of selected component (if applicable): policycoreutils-2.2.5-19.el7.x86_64 How reproducible: Each time. Provided Steps to Reproduce: 1. chcon unconfined_u:object_r:sandbox_file_t:s0:c446,c554 /tmp 2. restorecon -v /tmp 3. ls -lZd /tmp Actual results: the context is unconfined_u:object_r:sandbox_file_t:s0:c446,c554 Expected results: the context is system_u:object_r:tmp_t:s0 Additional info: I did tried on another platform, so maybe that's more than RHEL 7.2.
If that matter, /tmp is not a tmpfs. I did some tweak and it seems to be really just sandbox_file_t : ~ $ sudo chcon system_u:object_r:sandbox_file_t:s0 /tmp ~ $ sudo restorecon -v /tmp ~ $ sudo chcon system_u:object_r:etc_t:s0 /tmp/ ~ $ sudo restorecon -v /tmp restorecon reset /tmp context system_u:object_r:etc_t:s0->system_u:object_r:tmp_t:s0 I did test with other directories, and /root, /etc exhibit the same behavior. I also did test with others contexts, and so far, it work fine, except with sandbox_file_t.
So digging into the issue, that's because sandbox_file_t is listed in customizable_type. I am not sure on what would be a right fix, but I would expect at minima that restorecon -v tell me that it doesn't restore on purpose the context. But I agree that's a tricky problem to decide what is the right behavior :/
# ls -dZ /tmp/ drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp/ # chcon -t sandbox_file_t /tmp # ls -dZ /tmp/ drwxrwxrwt. root root system_u:object_r:sandbox_file_t:s0 /tmp/ # restorecon -RvF /tmp/ restorecon reset /tmp context system_u:object_r:sandbox_file_t:s0->system_u:object_r:tmp_t:s0 #
restorecon -F forces relabel, Ignores customizable types. But I would not advise this since things like containers, svirt, openshift, sandboxes all rely on this alternate label.
Well, that's because it is not advisable to use -F by default that I changed the title of this bug to be a RFE for "say something when something was not changed despites user expectation". I do not see how and why the fact that svirt openshift and others use that as a reason to not give more information to users, therefor, I reopen the RFE.
Ok, I can see this. Although it will potentially noisy on a full restore.
You can use restorecon -vv if you need more verbose output: # restorecon -vv /etc/machine-id restorecon: /etc/machine-id not reset customized by admin to system_u:object_r:svirt_sandbox_file_t:s0
I didn't knew there was 2 different level of verbosity, likely because that's neither in the man page, nor the --help output.
https://github.com/SELinuxProject/selinux/commit/bec41c4ff6d0cdf39c84c1c953ef486a056891da
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0913