Bug 1458831

Summary:	'/sbin/fixfiles restore' doesn't relabel all files when run from /.autorelabel or from system when some special files are present in /tmp
Product:	Red Hat Enterprise Linux 7	Reporter:	Ondrej Faměra <ofamera>
Component:	policycoreutils	Assignee:	Vit Mojzis <vmojzis>
Status:	CLOSED ERRATA	QA Contact:	Dalibor Pospíšil <dapospis>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.3	CC:	cww, dapospis, dwalsh, fadamo, herrold, lvrabec, mgrepl, mmalik, ofamera, plautrba, rmetrich, ssekidde, vmojzis, zpytela
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		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:
Bug Depends On:
Bug Blocks:	1420851, 1469954

Description Ondrej Faměra 2017-06-05 15:03:42 UTC

== Description of problem:
System doesn't relabel all files on '/' filesystem when using '/.autorelabel' or '/sbin/fixfiles restore' when structures generated by ReaR are present in the /tmp.

== Version-Release number of selected component (if applicable):
policycoreutils-2.5-11.el7_3

== How reproducible:
Always

== Steps to Reproduce:
1. Start with clean minimal RHEL 7.3 installation with defaults.
2. Follow procedure to make backup using ReaR in article https://access.redhat.com/solutions/2115051 with one exception -
configure variable BACKUP_PROG_EXCLUDE to not contain defaults so the '/tmp'
gets included in backup. For example use BACKUP_PROG_EXCLUDE=('/var/crash').

3. Try restoring the system from the generated backup.

== Actual results:
System restores from ReaR successfully, boot to relabel all files, reboot and fails to boot because some files were not relabelled correctly.

== Expected results:
System restores from ReaR successfully, boot to relabel all files, reboot and works normally.

== Additional info:
Investigating further if the system is is booted with 'enforcing=0' I can see that some files in system according to 'restorecon -vnR /' doesn't have correct label and has 'system_u:object_r:tmp_t:s0' label instead.
Files that has wrong label seems to be symlinked from /tmp/rear.*/ directories.
'/sbin/fixfiles restore' always exists with exit code 0 which I would expect means that files were relabelled correctly.

Running '/sbin/fixfiles restore' doesn't cause the files to get correct label.
Running 'restorecon -vR /' restores correct labels in system. I would expect that same would happen when '/.autorelabel' was created and system rebooted.

Comment 2 Daniel Walsh 2017-06-05 21:03:28 UTC

SELinux does not define labels for most content in /tmp, so fixfiles/restore does not modify the labels.  Any content labeled <<none>> will not be relabeled.

It is always best to remove all files in /tmp.  Or leave them with the label they had when they were moved there.

Comment 3 Ondrej Faměra 2017-06-06 07:41:26 UTC

Hi Dan,

I think I haven't explained correctly which files are not getting labelled correctly. I agree that there is no point in concerning about files /tmp. However I'm referring here to files in system like /usr/bin/true or /usr/lib64/libcrypto.so.1.0.0 and many others that will not have a correct label after either running '/sbin/fixfile restore' or making 'touch /.autorelabel; reboot'.

Is it expected behaviour that '/sbin/fixfiles restore' doesn't restore label on important system files in /usr/lib64 when some special files in /tmp are present and will exit with exit code '0'?

Ondrej

Comment 4 Daniel Walsh 2017-06-06 12:42:40 UTC

Yes fixfiles should fix the labels and not exit prematurely.

Comment 5 Vit Mojzis 2017-06-12 12:39:04 UTC

(In reply to Ondrej Faměra from comment #3)
> Hi Dan,
> 
> I think I haven't explained correctly which files are not getting labelled
> correctly. I agree that there is no point in concerning about files /tmp.
> However I'm referring here to files in system like /usr/bin/true or
> /usr/lib64/libcrypto.so.1.0.0 and many others that will not have a correct
> label after either running '/sbin/fixfile restore' or making 'touch
> /.autorelabel; reboot'.
> 
> Is it expected behaviour that '/sbin/fixfiles restore' doesn't restore label
> on important system files in /usr/lib64 when some special files in /tmp are
> present and will exit with exit code '0'?
> 
> Ondrej

Thank you for reporting the issue. 
I wasn't able to follow the provided reproducer (ReaR restore procedure corrupted my virtual machine's boot loader), could you possibly grant me access to your machine, or better yet provide an example of "special file in /tmp" (file which makes fixfiles crash)?

Comment 7 Vit Mojzis 2017-06-14 08:58:08 UTC

Turns out that fixfiles doesn't exit prematurely.
The "special files" in /tmp contain symbolic links (including links to files in /usr/lib64).
Last step of "fixfiles restore" procedure is labeling content of /tmp as tmp_t, which causes reported behaviour (some files in /usr/lib64 are labeled tmp_t because of the symbolic links).

Comment 8 Vit Mojzis 2017-06-28 07:52:33 UTC

The fix was already approved upstream:
https://github.com/SELinuxProject/selinux/commit/2608b4d6660af0fb8ad93f2cc144bdaab3c2afa8

Comment 12 Renaud Métrich 2018-02-16 12:25:43 UTC

*** Bug 1545664 has been marked as a duplicate of this bug. ***

Comment 15 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