Bug 1228489 - Fedora 22 net install sets /etc/passwd, /etc/group SELinux context to shadow_t
Summary: Fedora 22 net install sets /etc/passwd, /etc/group SELinux context to shadow_t
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1228200 (view as bug list)
Depends On:
Blocks: 1229788
TreeView+ depends on / blocked
 
Reported: 2015-06-05 04:50 UTC by Rob Foehl
Modified: 2015-07-17 05:14 UTC (History)
16 users (show)

Fixed In Version: selinux-policy-3.13.1-128.1.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1229788 (view as bug list)
Environment:
Last Closed: 2015-06-11 18:38:18 UTC
Type: Bug


Attachments (Terms of Use)
Logs from a test VM install this morning (1.13 MB, application/x-tar)
2015-06-05 14:40 UTC, Rob Foehl
no flags Details

Description Rob Foehl 2015-06-05 04:50:49 UTC
Description of problem:

Fedora 22 minimal network installs complete with /etc/passwd and /etc/group with an SELinux context of system_u:object_r:shadow_t, making them effectively unreadable.  This causes numerous failures during boot, long stalls, and eventually a system that rejects all login attempts.

The same (Fedora server) netinst media was used for a half dozen installs over the 5/30-5/31 weekend with no issues; issue being reported was first encountered on 6/4, and was reproducible in a VM on 6/5.  I haven't been able to track down which package(s) might have introduced this, so I'm opening against anaconda for now, although I suspect the real issue is elsewhere.


How reproducible:

100% on Fedora Server netinst media and current minimal package set from 2015-06-04.


Steps to Reproduce:
1. Boot Fedora Server netinst media
2. Select minimal package set, proceed with installation
3. Set a root password for recovery
4. Observe long delays, service failures during first boot
5. Single-user system (rescue boot doesn't work, either)
6. Run restorecon -Rv /etc
7. Reboot, observe normal boot process and functional login prompt


Additional info:

Here's what restorecon will do on a system in this state:

[root@test ~]# restorecon -Rv /etc
restorecon reset /etc/group context system_u:object_r:shadow_t:s0->system_u:object_r:passwd_file_t:s0
restorecon reset /etc/passwd context system_u:object_r:shadow_t:s0->system_u:object_r:passwd_file_t:s0

Comment 1 David Shea 2015-06-05 13:27:55 UTC
Please attach the log files from the install, available in /var/log/anaconda on the installed system.

Comment 2 Rob Foehl 2015-06-05 14:40:53 UTC
Created attachment 1035342 [details]
Logs from a test VM install this morning

Comment 3 Michal Schmidt 2015-06-05 16:03:32 UTC
I'm seeing this bug too.

I made a script to observe the changes to /etc/passwd's SELinux context during installation. I run it in the shell on TTY1:

while :; do
  a=$(ls -Z /mnt/sysimage/etc/passwd 2>/dev/null)
  if [ "$a" != "$b" ]; then
    tail -n1 /tmp/dnf.rpm.log
    echo "Change: $b -> $a"
  fi
done

Then from its output and the contents of my /tmp/dnf.rpm.log I deduced these facts:

1. /etc/passwd gets created during installation of the "setup" package with the correct label: passwd_file_t.
2. When "avahi-autoipd" is being installed, its %pre scriptlet calls groupadd and useradd. At this moment the context of /etc/passwd changes to shadow_t.
3. Possibly relevant: "selinux-policy-targeted" is installed later, as one of the last packages.

Comment 4 Michal Schmidt 2015-06-05 16:06:32 UTC
(In reply to Michal Schmidt from comment #3)
I lost a line in the script. Fixed script:

while :; do
  a=$(ls -Z /mnt/sysimage/etc/passwd 2>/dev/null)
  if [ "$a" != "$b" ]; then
    tail -n1 /tmp/dnf.rpm.log
    echo "Change: $b -> $a"
    b="$a"
  fi
done

Comment 5 Michal Schmidt 2015-06-05 16:16:22 UTC
If instead of Minimal Install I select the default Fedora Server, the sequence is the following:

1. /etc/passwd gets created during installation of the "setup" package with the correct label: passwd_file_t.  (Same as with Minimal)
2. When "tog-pegasus-libs" is being installed, its %pre scriptlet calls groupadd and useradd. At this moment the context of /etc/passwd changes to shadow_t.
3. At some point "selinux-policy-targeted" is installed.
4. The first package afterwards to use groupadd/useradd in its %pre is "tcpdump". When it is being installed, the context of /etc/passwd changes back to passwd_file_t.

I hope this helps understanding why the problem is seen only with Minimal install and not with Server.

Comment 6 Michal Schmidt 2015-06-05 16:36:29 UTC
I wanted to test what happens when installing without the updates repo enabled, but I am unable to, because of bug 1211907.

Comment 7 Michal Schmidt 2015-06-05 16:58:37 UTC
OK, I was able to test minimal installation without updates by entering the URL instead of using "Closest mirror".

When not using the updates repo for installation I can see that /etc/passwd gets created as passwd_file_t and it never changes. This is as it should be.

So which update broke it? I'm guessing... this libselinux update which went stable recently:
https://admin.fedoraproject.org/updates/FEDORA-2015-8872/libselinux-2.3-10.fc22

Comment 8 David Shea 2015-06-05 17:16:19 UTC
Changing whatever update caused the problem to not break F22 installs is probably for the best, but in the world of tomorrow anaconda could just go ahead and relabel the password and group files in %post. It already does that for shadow. https://github.com/rhinstaller/anaconda/pull/129

Comment 9 Rob Foehl 2015-06-05 17:23:26 UTC
Interesting -- I'd attempted to test yesterday without installing updates and had the same issue, but I wasn't aware of bug 1211097.  That and the useradd hint mentioned above were starting to make me think I'd somehow dodged this in earlier installs and the issue may have been around longer than initially thought.

Just tried to reproduce again while allowing chrony to be installed, but that user/group addition didn't change anything.  The libselinux update looks like a good candidate...

Comment 10 Rob Foehl 2015-06-05 17:25:12 UTC
Oops, that should've been bug 1211907...

Comment 11 Michal Schmidt 2015-06-05 17:29:35 UTC
To confirm that the change in libselinux is the cause of this bug I made a mockbuild of libselinux-2.3-9 (the original F22 release) just with the release field bumped to 10.fc22.m1 (so that it looks newer than the release currently in updates). I pointed Anaconda to it as an additional repo:
  https://michich.fedorapeople.org/f22-libselinux/

With it the resulting installation has /etc/passwd labeled correctly and there's no problem booting it.

Comment 12 David Shea 2015-06-08 14:45:32 UTC
Pushed the anaconda change to rawhide.

Comment 13 Petr Lautrbach 2015-06-08 14:46:02 UTC
It's really related to the latest libselinux change. We consider SELinux as disabled when there's no /etc/selinux/config file, see bug #1219045.

It means that for groupadd, a system seams to be with SELinux disabled until the selinux-policy package is installed. In this case, groupadd doesn't care of a context of a new /ec/group file and this file gets context from the load policy and its type transition rule - when a file is created in a 'etc_t' directory by a 'groupadd_t' process then the will have 'shadow_t' type.

I can see several solutions here:

1. revert the change for #1219045 and consider SELinux disabled only if a system is run with a kernel without SELinux support or with selinux=0 - it will break setup without selinux-policy and without explicitly disabled SELinux 

2. change anaconda to copy /etc/selinux/config file from a ramdisk to chroot

3. install selinux-policy-targeted package as soon as possible in the installation transaction

Comment 14 Brian Lane 2015-06-09 00:15:25 UTC
Maybe anaconda, or selinux (with some switch to control the behavior) should be relabeling everything? Since we can't really know for sure what's going to be installed with the wrong label before selinux is installed I think we need a more generic solution.

Having anaconda do it at the end of the installation would be safest, but add the most time. Having some kind of switch to communicate to the selinux rpm install would be faster since it would only run on what has been installed up to that point.

Note that there is no way for us to control the order that things are installed in.

Comment 15 jamespharvey20 2015-06-09 01:12:01 UTC
Duplicate of bug 1228200

Comment 16 Michal Schmidt 2015-06-09 10:50:10 UTC
*** Bug 1228200 has been marked as a duplicate of this bug. ***

Comment 17 Petr Lautrbach 2015-06-09 14:11:39 UTC
Currently, selinux-policy package restores contexts only on "/root /var/log /run" during install while it also restores contexts on "/etc/passwd* /etc/group* /etc/*shadow*" during update. I think that selinux-policy could safely restore contexts of "/etc/passwd* /etc/group* /etc/*shadow*" in the install phase as well.

--- a/selinux-policy.spec
+++ b/selinux-policy.spec
@@ -306,7 +306,7 @@ if [ -e /etc/selinux/%2/.rebuild ]; then \
 fi; \
 [ "${SELINUXTYPE}" == "%2" ] && selinuxenabled && load_policy; \
 if [ %1 -eq 1 ]; then \
-   /sbin/restorecon -R /root /var/log /run 2> /dev/null; \
+   /sbin/restorecon -R /root /var/log /run /etc/passwd* /etc/group* /etc/*shadow* 2> /dev/null; \
 else \
 %relabel %2 \
 fi;

Comment 18 Miroslav Grepl 2015-06-09 14:13:34 UTC
Yes, I agree.

Fixed in selinux-policy-3.13.1-128.1.fc22.

Comment 19 Fedora Update System 2015-06-09 14:39:42 UTC
selinux-policy-3.13.1-128.1.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/selinux-policy-3.13.1-128.1.fc22

Comment 20 Petr Schindler 2015-06-09 15:15:44 UTC
I tried minimal installation with new selinux-policy 3.13.1-128.1 and it booted correctly. This bug seems to be fixed.

Comment 21 Michal Schmidt 2015-06-09 15:20:08 UTC
That's great! But we should let Bodhi move this through the Bugzilla states (ON_QA and eventually CLOSED).

Comment 22 Rob Foehl 2015-06-09 15:41:55 UTC
Would it not also make sense to implement the suggestion from comment 13 that /etc/selinux/config be copied to the chroot early in the install process?

Relabeling the errant files after the fact is fine, but having broken SELinux state throughout the install process (enabled, but userspace doesn't think so) seems like it's asking for more trouble.

Comment 23 Petr Lautrbach 2015-06-09 15:45:52 UTC
I've cloned this bug to anaconda so it could be discussed and fixed on the other side.

Comment 24 Fedora Update System 2015-06-10 19:11:29 UTC
Package selinux-policy-3.13.1-128.1.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.13.1-128.1.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-9714/selinux-policy-3.13.1-128.1.fc22
then log in and leave karma (feedback).

Comment 25 Fedora Update System 2015-06-11 18:38:18 UTC
selinux-policy-3.13.1-128.1.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 ILMostro 2015-07-17 05:12:29 UTC
After the update to Fedora22 it seems that some users and/or groups are created (added to /etc/passwd /etc/group) that were not there before.  Here's part of a mail message from my rkhunter scan after doing "fedup" from F20 to F22:

Warning: Changes found in the passwd file for user 'zabbixsrv':
         The GID has changed from '973' to '961'
Warning: User 'systemd-timesync' has been added to the passwd file.
Warning: User 'systemd-network' has been added to the passwd file.
Warning: User 'systemd-resolve' has been added to the passwd file.
Warning: User 'systemd-bus-proxy' has been added to the passwd file.
Warning: User 'setroubleshoot' has been added to the passwd file.
Warning: Group 'input' has been added to the group file.
Warning: Group 'systemd-timesync' has been added to the group file.
Warning: Group 'systemd-network' has been added to the group file.
Warning: Group 'systemd-resolve' has been added to the group file.
Warning: Group 'systemd-bus-proxy' has been added to the group file.
Warning: Group 'setroubleshoot' has been added to the group file.
Warning: Group 'libvirt' has been added to the group file.
Warning: Group 'zabbixsrv' has been added to the group file.

Therefore, I'm not entirely certain that this bug was introduced by or directly related to SELinux! Any thoughts or confirmation? It might be lack of coordination between certain packages during upgrade process, including selinux-policy.

Additionally, some SELinux filetypes in the `/etc/` directory get mocked up as well; including /etc/chronyd.keys and  

restorecon reset /etc/radicale context system_u:object_r:unlabeled_t:s0->system_u:object_r:radicale_etc_t:s0
restorecon set context /etc/radicale->system_u:object_r:radicale_etc_t:s0 failed:'Invalid argument'
restorecon reset /etc/sgml/catalog context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0
restorecon reset /etc/sgml/checkstyle-5.8-2.fc22.cat context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0
restorecon reset /etc/dconf/db/ibus context system_u:object_r:etc_runtime_t:s0->system_u:object_r:etc_t:s0

Comment 27 ILMostro 2015-07-17 05:14:09 UTC
Note, my installation was NOT "minimal"; I had a Desktop version of F20 and updated to "Workstation".


Note You need to log in before you can comment on or make changes to this bug.