Bug 1260238

Summary:	RFE: restorecon should say in verbose mode when it doesn't change a context due to customizable_type
Product:	Red Hat Enterprise Linux 7	Reporter:	M. Scherer <mscherer>
Component:	policycoreutils	Assignee:	Petr Lautrbach <plautrba>
Status:	CLOSED ERRATA	QA Contact:	Dalibor Pospíšil <dapospis>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	dwalsh, lvrabec, mgrepl, mmalik, mthacker, plautrba, pvrabec, ssekidde, vmojzis
Target Milestone:	rc	Keywords:	Documentation, FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:
Clones:	1513098 (view as bug list)		Environment:
Last Closed:	2018-04-10 16:36:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description M. Scherer 2015-09-04 21:48:20 UTC

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.

Comment 2 M. Scherer 2015-09-04 22:10:09 UTC

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.

Comment 3 M. Scherer 2015-09-05 00:19:53 UTC

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 :/

Comment 4 Milos Malik 2015-09-07 07:18:40 UTC

# 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
#

Comment 5 Daniel Walsh 2015-09-07 12:04:59 UTC

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.

Comment 6 M. Scherer 2015-09-07 14:57:23 UTC

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.

Comment 7 Daniel Walsh 2015-09-09 14:42:38 UTC

Ok, I can see this.  Although it will potentially noisy on a full restore.

Comment 9 Petr Lautrbach 2016-07-19 19:20:07 UTC

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

Comment 10 M. Scherer 2016-07-19 19:39:35 UTC

I didn't knew there was 2 different level of verbosity, likely because that's neither in the man page, nor the --help output.

Comment 11 Petr Lautrbach 2017-06-29 13:23:33 UTC

https://github.com/SELinuxProject/selinux/commit/bec41c4ff6d0cdf39c84c1c953ef486a056891da

Comment 19 errata-xmlrpc 2018-04-10 16:36:29 UTC

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