Bug 1333952

Summary: Wrong SELinux label on /etc/group after installation
Product: Red Hat Enterprise Linux 7 Reporter: Brian Lane <bcl>
Component: selinux-policyAssignee: Lukas Vrabec <lvrabec>
Status: CLOSED ERRATA QA Contact: Stefan Dordevic <sdordevi>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.3CC: bcl, lcapitulino, lvrabec, mgrepl, mmalik, plautrba, pvrabec, sdordevi, ssekidde
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-3.13.1-72.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 02:28:46 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:
Attachments:
Description Flags
journalctl output while trying to sudo
none
restorecon -rv / output
none
packaging.log none

Description Brian Lane 2016-05-06 19:00:33 UTC
New minimal install of 7.3 nightly, user setup to be a member of the wheel group so that sudo will work. Reboot system and login, id shows:

uid=1000(bcl) gid=1000(bcl) groups=1000(bcl) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

When I boot with enforcing=0 id reports:

uid=1000(bcl) gid=1000(bcl) groups=1000(bcl),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


This is with selinux-policy-3.13.1-70.el7.noarch

Comment 1 Brian Lane 2016-05-06 19:02:26 UTC
Created attachment 1154729 [details]
journalctl output while trying to sudo

Here's a journalctl log with selinux permissive, trying to sudo. Also includes setting it to permissive without reboot, and finally adding user to /etc/sudoers.

Comment 2 Brian Lane 2016-05-06 20:39:48 UTC
running restorecon -rv /etc changes /etc/group from :shadow_t to :passwd_file_t

Comment 4 Petr Lautrbach 2016-05-09 08:03:50 UTC
It's probably already reported and fixed problem in lorax - https://bugzilla.redhat.com/show_bug.cgi?id=1332147

Please try the latest compose where it should be fixed.

Comment 5 Brian Lane 2016-05-11 18:07:39 UTC
Created attachment 1156249 [details]
restorecon -rv / output

No, this is a different problem. Login works fine and most of the filesystem is labeled correctly.

Comment 6 Petr Lautrbach 2016-05-13 05:39:18 UTC
Note: The cause of this bug is probably same as for https://bugzilla.redhat.com/show_bug.cgi?id=1334800

Comment 7 Brian Lane 2016-05-13 22:39:54 UTC
*** Bug 1334800 has been marked as a duplicate of this bug. ***

Comment 8 Brian Lane 2016-05-13 22:52:54 UTC
This is related to the change in selinux requiring /etc/selinux/config to exist.

The current lorax sets this up in the installer environment, which has fixed most of the problems people were seeing (no login to new system for example).

I ran some tests today and if I create an empty /mnt/sysimage/etc/selinux/config in a kickstart %pre-install section (this runs right before package installation) then /etc/group has the correct label.

If I run a restorecon on the new system it still fixes/complains about all the *other* entries in comment 5 as well as the /etc/selinux/config file.

Everything else is ok.

I'm not sure why selinux acts this way, but given that it almost gets it all correct I think the fix lies with selinux, not Anaconda.

Note that anaconda has no control over the order of package installation, and that selinux-policy is the 177th package installed. /etc/group is installed by setup which is the 3rd package installed.

Comment 9 Brian Lane 2016-05-13 22:54:51 UTC
Created attachment 1157401 [details]
packaging.log

Packages installed and their order.

Comment 10 Petr Lautrbach 2016-05-16 07:19:35 UTC
Thanks for the investigation. Indeed it's missing fix in selinux-policy.spec file - 
http://pkgs.fedoraproject.org/cgit/rpms/selinux-policy.git/commit/?id=19cd06ec8a0214a9dc09ca80ae3c757b2b7e248d 

This commit needs to be backported.

Comment 14 errata-xmlrpc 2016-11-04 02:28:46 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://rhn.redhat.com/errata/RHBA-2016-2283.html