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
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
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
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.
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.
Created attachment 518394 [details] File from System that faulted
Created attachment 518395 [details] audit.log from system which faulted
Created attachment 518396 [details] install log
Created attachment 518397 [details] install log syslog
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
same here cant boot after installing x86_64 16 rc4
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
Created attachment 518413 [details] systemd 'permission denied' errors trying to boot x86_64 RC4 install
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
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.
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
Created attachment 518430 [details] 'restorecon -nvr /' output on i686
Created attachment 518431 [details] 'restorecon -nvr /' output on x86_64
*** Bug 730873 has been marked as a duplicate of this bug. ***
Also reproduced I think with net install of RC4 x86_64 (with encryption fwiw).
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?
(In reply to comment #20) > > What version of selinux-policy are you using? selinux-policy-3.10.0-15
Can we please get this updated to at least 17 if not 18 for the release...
That was the default installed with F16 Alpha RC4, I think we need a new compose with -18 (maybe RC5).
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.
Created attachment 518503 [details] anaconda log
Created attachment 518507 [details] anaconda.log from liveinst (F16 Alpha RC4 KDE)
https://bugzilla.redhat.com/attachment.cgi?id=518389 from Bug 730873 is another.
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?
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.
Does updates=http://clumens.fedorapeople.org/730863.img fix it?
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!
(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.
Mine was a default Graphical Desktop install.
Tested with minimal network installation, confirm the fix.
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.
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
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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
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.
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.
Confirmed it fixed by net-installing F16-alpha-rc5 by anaconda 16.14.6.
I also confirmed this fix with a live install of RC5, setting VERIFIED.
RC5 x86_64 minimal netinstall looks good to me too.
FWIF:Also confirmed this fix with Alpha RC5 x86_64 default DVD installation.
I will look into fixing matchpathcon to add realpath functionality.
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).
biff-baff!
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.