Bug 730863 - /usr/lib64 and /lib64 incorrectly SELinux-labelled after installation of Fedora 16 Alpha RC4
/usr/lib64 and /lib64 incorrectly SELinux-labelled after installation of Fedo...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
16
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
AcceptedBlocker
:
: 730873 (view as bug list)
Depends On:
Blocks: F16Alpha/F16AlphaBlocker
  Show dependency treegraph
 
Reported: 2011-08-15 21:57 EDT by Athmane Madjoudj
Modified: 2011-08-18 18:24 EDT (History)
17 users (show)

See Also:
Fixed In Version: anaconda-16.14.6-1.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-18 18:24:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File from System that faulted (1.37 KB, text/plain)
2011-08-16 00:43 EDT, Robert Lightfoot
no flags Details
audit.log from system which faulted (10.63 KB, text/plain)
2011-08-16 00:51 EDT, Robert Lightfoot
no flags Details
install log (64.01 KB, text/plain)
2011-08-16 00:55 EDT, Robert Lightfoot
no flags Details
install log syslog (9.56 KB, text/plain)
2011-08-16 00:58 EDT, Robert Lightfoot
no flags Details
systemd 'permission denied' errors trying to boot x86_64 RC4 install (121.74 KB, image/png)
2011-08-16 03:36 EDT, Adam Williamson
no flags Details
restorecon -vnR / on x86_64 system installed from Alpha RC4 DVD (9.25 KB, text/plain)
2011-08-16 04:36 EDT, Sandro Mathys
no flags Details
'restorecon -nvr /' output on i686 (11.25 KB, text/plain)
2011-08-16 04:58 EDT, Adam Williamson
no flags Details
'restorecon -nvr /' output on x86_64 (11.95 KB, text/plain)
2011-08-16 04:59 EDT, Adam Williamson
no flags Details
anaconda log (22.03 KB, text/plain)
2011-08-16 10:42 EDT, Athmane Madjoudj
no flags Details
anaconda.log from liveinst (F16 Alpha RC4 KDE) (12.48 KB, text/x-log)
2011-08-16 10:47 EDT, Sandro Mathys
no flags Details

  None (edit)
Description Athmane Madjoudj 2011-08-15 21:57:41 EDT
Description of problem:

After installation of a fresh Fedora 16 Alpha RC4, the installed system is not bootable until forcing relabel (or disabling enforcing at boot)


# grep AVC /var/log/audit/audit.log

type=AVC msg=audit(1313459254.022:4): avc:  denied  { getattr } for  pid=600 comm="modprobe" path="socket:[11266]" dev=sockfs ino=11266 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket


# sealert -a /var/log/audit/audit.log

found 1 alerts in /var/log/audit/audit.log
--------------------------------------------------------------------------------

SELinux is preventing /sbin/modprobe from getattr access on the unix_stream_socket unix_stream_socket.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that modprobe should be allowed getattr access on the unix_stream_socket unix_stream_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep modprobe /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp



How reproducible:
100%

Steps to Reproduce:
1. Install Fedora 16 Alpha RC4
2. Reboot
  
Actual results:
System not bootable

Expected results:
System bootable
Comment 1 Adam Williamson 2011-08-15 22:22:43 EDT
Similar issue with an encrypted system installed from live image, fails to boot post-install, but boots with enforcing=0. Nothing in /var/log/audit/audit.log , but dmesg | grep avc returns:

    [ 15.305172] type=1400 audit(1313460801.621:3): avc: denied { read } for pid=647 comm="udevd" name="modules.devname" dev=dm-2 ino=32647 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file
    [ 15.305206] type=1400 audit(1313460801.621:4): avc: denied { open } for pid=647 comm="udevd" name="modules.devname" dev=dm-2 ino=32647 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file
    [ 15.305328] type=1400 audit(1313460801.621:5): avc: denied { getattr } for pid=647 comm="udevd" path="/lib/modules/3.0.0-1.fc16.x86_64/modules.devname" dev=dm-2 ino=32647 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file
    [ 20.837244] type=1400 audit(1313460807.160:6): avc: denied { getattr } for pid=1170 comm="modprobe" path="socket:[17583]" dev=sockfs ino=17583 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
    [ 21.618662] type=1400 audit(1313460807.942:7): avc: denied { read } for pid=1208 comm="ssh-keygen" name="fips_enabled" dev=proc ino=6039 scontext=system_u:system_r:ssh_keygen_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
    [ 21.618685] type=1400 audit(1313460807.942:8): avc: denied { open } for pid=1208 comm="ssh-keygen" name="fips_enabled" dev=proc ino=6039 scontext=system_u:system_r:ssh_keygen_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file
    [ 22.494067] dbus[1233]: avc: netlink poll: error 4



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 2 Adam Williamson 2011-08-15 22:24:35 EDT
Nominating as Alpha blocker :/. I can separate my bug out if it seems to be a different root cause.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Andre Robatino 2011-08-15 23:46:33 EDT
This problem is x86_64 specific. An i386 install boots without having to relabel or use enforcing=0, and "sealert -a /var/log/audit/audit.log" on i386 returns 0 alerts.
Comment 4 Robert Lightfoot 2011-08-16 00:41:22 EDT
I saw this on an F16alphaRC4x86_64 system without encryption or LVM in use.  Adding enforcing=0 to kernel boot line allowed successful start.  Performing restorecon -R ./ from / resolved for future boots.
Comment 5 Robert Lightfoot 2011-08-16 00:43:46 EDT
Created attachment 518394 [details]
File from System that faulted
Comment 6 Robert Lightfoot 2011-08-16 00:51:33 EDT
Created attachment 518395 [details]
audit.log from system which faulted
Comment 7 Robert Lightfoot 2011-08-16 00:55:05 EDT
Created attachment 518396 [details]
install log
Comment 8 Robert Lightfoot 2011-08-16 00:58:28 EDT
Created attachment 518397 [details]
install log syslog
Comment 9 Adam Williamson 2011-08-16 03:27:49 EDT
From an x86_64 DVD install, all defaults all the way through, again fails on boot, with enforcing=0 boot succeeds with:

Aug 15 21:57:10 localhost dbus[692]: avc:  netlink poll: error 4
Aug 15 21:57:10 localhost dbus[692]: avc:  netlink poll: error 4
Aug 15 21:57:10 localhost kernel: [   15.936355] type=1400 audit(1313470629.175:3): avc:  denied  { getattr } for  pid=642 comm="avahi-daemon" path="/lib64" dev=dm-1 ino=259592 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:etc_runtime_t:s0 tclass=dir
Aug 15 21:57:10 localhost kernel: [   16.925725] type=1400 audit(1313470630.164:4): avc:  denied  { getattr } for  pid=718 comm="modprobe" path="socket:[12352]" dev=sockfs ino=12352 scontext=system_u:system_r:insmod_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket

seems thin. I don't think avahi could cause such mayhem. It may be the modprobe.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Christopher Patrick 2011-08-16 03:31:07 EDT
same here cant boot after installing x86_64 16 rc4
Comment 11 Adam Williamson 2011-08-16 03:33:58 EDT
Attaching a screenshot which shows what I see when booting with SELinux enforcing after an x86-64 DVD install.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Adam Williamson 2011-08-16 03:36:01 EDT
Created attachment 518413 [details]
systemd 'permission denied' errors trying to boot x86_64 RC4 install
Comment 13 Adam Williamson 2011-08-16 04:29:59 EDT
So, confirmed that identical x86_64 and i686 live install paths show the same behaviour: x86_64 fails unless enforcing=0 is passed, i686 works.

In sum, it seems like this bug affects all x86_64 install paths so far tested - live, DVD, net install - and does not affect any i686 path.

Interestingly, if I watch i686 boot closely, I see the same 'permission denied' errors scroll past, so they don't seem to be the problem. SELinux shows no alerts, so it does seem like x86_64 gets those modprobe and avahi-daemon denials but i686 doesn't.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Sandro Mathys 2011-08-16 04:36:38 EDT
Created attachment 518421 [details]
restorecon -vnR / on x86_64 system installed from Alpha RC4 DVD

So, I think I see the same issues on my x86_64 installation. restorecon -vnR / shows a couple of problems but most important here seem the wrong labels on /lib64 and /usr/lib64 which also explains the difference to the i686 installations that Adam mentioned.
Comment 15 Adam Williamson 2011-08-16 04:57:02 EDT
I'm attaching the outputs of 'restorecon -nvr /' (which, to be clear, essentially displays incorrect labels) on two installs that are identical other than the arch in use. as Sandro spotted, major difference is that /lib64 and /usr/lib64 are mislabelled on the x86_64 install. so this bug may 'exist' in both arches, but only affect x86_64, because the labelling of /lib64 and /usr/lib64 doesn't matter at all to i686.

Procedure was to install from the desktop live, in KVM, straight through defaults, create a user named 'test' (password 'test'), log in as that user, open a terminal, run the command.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 16 Adam Williamson 2011-08-16 04:58:54 EDT
Created attachment 518430 [details]
'restorecon -nvr /' output on i686
Comment 17 Adam Williamson 2011-08-16 04:59:26 EDT
Created attachment 518431 [details]
'restorecon -nvr /' output on x86_64
Comment 18 Adam Williamson 2011-08-16 05:24:55 EDT
*** Bug 730873 has been marked as a duplicate of this bug. ***
Comment 19 Jens Petersen 2011-08-16 06:26:18 EDT
Also reproduced I think with net install of RC4 x86_64 (with encryption fwiw).
Comment 20 Daniel Walsh 2011-08-16 07:32:06 EDT
restorecon reset /lib64 context system_u:object_r:etc_runtime_t:s0->system_u:object_r:lib_t:s0

Is the obvious problem. 

This looks like anaconda created this directory with the wrong label at installation time.  It might need to be added to its list of restores.

What version of selinux-policy are you using?
Comment 21 Athmane Madjoudj 2011-08-16 07:44:01 EDT
(In reply to comment #20)

> 
> What version of selinux-policy are you using?

selinux-policy-3.10.0-15
Comment 22 Daniel Walsh 2011-08-16 08:21:01 EDT
Can we please get this updated to at least 17 if not 18 for the release...
Comment 23 Athmane Madjoudj 2011-08-16 08:32:59 EDT
That was the default installed with F16 Alpha RC4, I think we need a new compose with -18 (maybe RC5).
Comment 24 Chris Lumens 2011-08-16 10:36:15 EDT
Can someone who's seeing this problem attach /var/log/anaconda/anaconda.log from the installed system to this bug report?  We should already be relabeling /lib64.
Comment 25 Athmane Madjoudj 2011-08-16 10:42:31 EDT
Created attachment 518503 [details]
anaconda log
Comment 26 Sandro Mathys 2011-08-16 10:47:27 EDT
Created attachment 518507 [details]
anaconda.log from liveinst (F16 Alpha RC4 KDE)
Comment 27 John Reiser 2011-08-16 11:11:52 EDT
https://bugzilla.redhat.com/attachment.cgi?id=518389 from Bug 730873 is another.
Comment 28 Tim Flink 2011-08-16 11:36:06 EDT
I've tried a couple of things with minimal installs from custom boot.iso composes:

1. compose with anaconda-16.14.5-1.fc16 and selinux-policy-3.10.0-18.fc16
  - Same result, non bootable install

2. compose using anaconda-16.14.4-1.fc16 and selinux-policy-3.10.0-15.fc16
  - Same result, non bootable install

I'm not quite sure what caused the breakage here, any suggestions on what else to try?
Comment 29 Chris Lumens 2011-08-16 11:48:41 EDT
Labels look correct at the end of a minimal installation.  I'm now testing to see if something during initial bootup is causing the problem.  More help there would be handy.

Nothing between anaconda-16.14.4 and anaconda-16.14.5 should have caused this.  The only change was for bug 729599.
Comment 30 Chris Lumens 2011-08-16 13:46:23 EDT
Does updates=http://clumens.fedorapeople.org/730863.img fix it?
Comment 31 Adam Williamson 2011-08-16 14:20:00 EDT
Tested with a minimal DVD install, fix works: label on /lib64 is correct, installed system boots. Will now check with a full install. Can we get a new anaconda build with the fix, so I can check live install as well? Thanks!
Comment 32 John Reiser 2011-08-16 14:21:11 EDT
(In reply to comment #30)
> Does updates=http://clumens.fedorapeople.org/730863.img fix it?

Works for me: fresh install from RC4 DVD, appending " updates=..." to the boot command line for the installer.
Comment 33 John Reiser 2011-08-16 14:22:17 EDT
Mine was a default Graphical Desktop install.
Comment 34 Athmane Madjoudj 2011-08-16 14:53:02 EDT
Tested with minimal network installation, confirm the fix.
Comment 35 Chris Lumens 2011-08-16 15:15:13 EDT
Here's some more data.

The fix is:  http://fpaste.org/nQQb/ .  Note that I've removed the double slashes there.  If I check with the python selinux module, you'll see where the problem behavior occurs:

clumens@exeter:~/src/anaconda$ ipython
In [1]: import selinux

In [2]: selinux.matchpathcon("/lib64", 0)
Out[2]: [0, 'system_u:object_r:lib_t:s0']

In [3]: selinux.matchpathcon("//lib64", 0)
Out[3]: [0, 'system_u:object_r:etc_runtime_t:s0']

So, we can take the anaconda fix and rebuild for F16 alpha.  We could also consider this a bug in libselinux-python behavior (at the least, this worked fine in F15) and fix it there for F16 alpha.  Personally, I'd go with whatever makes for less work on the alpha.  I can always do the anaconda change for beta, just for complete correctness.
Comment 36 Adam Williamson 2011-08-16 15:17:31 EDT
So we tracked this one down exactly. The problem is in selinux-python, and it's easy to describe using ipython...on F15:

 In [3]: selinux.matchpathcon("//lib64", 0)
 Out[3]: [0, 'system_u:object_r:lib_t:s0']

on F16:

 In [5]: selinux.matchpathcon("//lib64", 0)
 Out[5]: [0, 'system_u:object_r:etc_runtime_t:s0']

in other words, matchpathcon can handle redundant slashes in paths in F15, but in F16, it can't. anaconda passes //lib64 and /usr//lib64 to it, and has for quite a while. This explains something which puzzled clumens - why the offending anaconda code was in F15, but we didn't hit this bug.

anaconda should probably be fixed to drop the redundant slashes, and we can fix this bug for Alpha that way if necessary, but it might be a better/smaller fix to fix selinux-python to handle redundant slashes again, and fix anaconda post-Alpha.

This bug was actually present in all prior TCs and RCs, but was disguised by https://bugzilla.redhat.com/show_bug.cgi?id=729563 , the bug that SELinux was disabled by default on DVD/net installs, and by https://bugzilla.redhat.com/show_bug.cgi?id=728863 , another bug preventing SELinux-enabled systems from booting, on live installs. Workarounds for those bugs involved disabling SELinux or doing a relabel, which rather hid this bug.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 37 Adam Williamson 2011-08-16 15:33:11 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 38 Fedora Update System 2011-08-16 16:14:16 EDT
anaconda-16.14.6-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/anaconda-16.14.6-1.fc16
Comment 39 Adam Williamson 2011-08-16 17:04:43 EDT
Discussed in an impromptu blocker review in #fedora-qa on 2011-08-16. Accepted as a blocker under the criterion "In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The firstboot utility must be able to create a working user account" with +1s from myself, tflink, red_alert (sandro mathys), dgilmore.
Comment 40 Andre Robatino 2011-08-16 21:29:40 EDT
Confirmed that an RC5 x86_64 text install from the DVD boots without having to relabel, although I see permission denied errors, similar to the ones on i386.
Comment 41 He Rui 2011-08-16 23:08:32 EDT
Confirmed it fixed by net-installing F16-alpha-rc5 by anaconda 16.14.6.
Comment 42 Adam Williamson 2011-08-17 01:40:10 EDT
I also confirmed this fix with a live install of RC5, setting VERIFIED.
Comment 43 Jens Petersen 2011-08-17 03:50:48 EDT
RC5 x86_64 minimal netinstall looks good to me too.
Comment 44 Sandro Mathys 2011-08-17 03:57:24 EDT
FWIF:Also confirmed this fix with Alpha RC5 x86_64 default DVD installation.
Comment 45 Daniel Walsh 2011-08-17 08:05:12 EDT
I will look into fixing matchpathcon to add realpath functionality.
Comment 46 Fedora Update System 2011-08-17 10:54:54 EDT
Package anaconda-16.14.6-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-16.14.6-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/anaconda-16.14.6-1.fc16
then log in and leave karma (feedback).
Comment 47 Adam Williamson 2011-08-17 12:28:38 EDT
biff-baff!
Comment 48 Fedora Update System 2011-08-18 18:23:51 EDT
anaconda-16.14.6-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

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