Red Hat Bugzilla – Bug 694239
Live image built with latest systemd/selinux-policy etc fails to boot with selinux enabled
Last modified: 2011-04-11 11:18:13 EDT
I built a live image with all the recent updates for systemd, selinux etc for the /run stuff, to check that it works. Unfortunately, it doesn't. With these packages: systemd-23-1.fc15 libselinux-2.0.99-4.fc15 (-6 has not been submitted as an update and isn't currently slated to make beta) selinux-policy-3.9.16-12.fc15 udev-167-2.fc15 filesystem-2.4.40-1.fc15 the system fails to boot unless I use selinux=0 (in which case it boots fine). I get denials for various things: Apr 6 19:04:29 localhost kernel: [ 7.499205] type=1400 audit(1302116665.198:3): avc: denied { read } for pid=421 comm="mount" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:mount_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 7.640587] type=1400 audit(1302131065.340:4): avc: denied { read } for pid=443 comm="sh" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:loadkeys_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.120348] type=1400 audit(1302131068.826:5): avc: denied { read } for pid=861 comm="systemd-tmpfile" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.295097] type=1400 audit(1302131069.001:6): avc: denied { read } for pid=848 comm="plymouthd" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:plymouthd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.514857] type=1400 audit(1302131069.221:7): avc: denied { read } for pid=870 comm="alsactl" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.860790] type=1400 audit(1302131069.568:8): avc: denied { read } for pid=876 comm="NetworkManager" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.882911] type=1400 audit(1302131069.590:9): avc: denied { read } for pid=899 comm="mcelog" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:mcelog_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.884747] type=1400 audit(1302131069.592:10): avc: denied { read } for pid=876 comm="NetworkManager" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:29 localhost kernel: [ 11.951879] type=1400 audit(1302131069.659:11): avc: denied { read } for pid=901 comm="rsyslogd" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:syslogd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:30 localhost dbus: avc: netlink poll: error 4 Apr 6 19:04:30 localhost kernel: [ 12.729150] type=1400 audit(1302131070.438:14): avc: denied { read } for pid=927 comm="dbus-daemon-lau" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:30 localhost kernel: [ 12.755755] type=1400 audit(1302131070.464:15): avc: denied { read } for pid=928 comm="polkitd" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:policykit_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:30 localhost kernel: [ 12.780614] type=1400 audit(1302131070.489:16): avc: denied { read } for pid=876 comm="NetworkManager" name="n2" dev=tmpfs ino=10827 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.780632] type=1400 audit(1302131070.489:17): avc: denied { open } for pid=876 comm="NetworkManager" name="n2" dev=tmpfs ino=10827 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.780651] type=1400 audit(1302131070.489:18): avc: denied { getattr } for pid=876 comm="NetworkManager" path="/run/udev/data/n2" dev=tmpfs ino=10827 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.798663] type=1400 audit(1302131070.507:19): avc: denied { read } for pid=931 comm="modem-manager" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:modemmanager_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file Apr 6 19:04:30 localhost kernel: [ 12.850823] type=1400 audit(1302131070.559:20): avc: denied { read } for pid=931 comm="modem-manager" name="c4:64" dev=tmpfs ino=9806 scontext=system_u:system_r:modemmanager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.850876] type=1400 audit(1302131070.560:21): avc: denied { open } for pid=931 comm="modem-manager" name="c4:64" dev=tmpfs ino=9806 scontext=system_u:system_r:modemmanager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.850926] type=1400 audit(1302131070.560:22): avc: denied { getattr } for pid=931 comm="modem-manager" path="/run/udev/data/c4:64" dev=tmpfs ino=9806 scontext=system_u:system_r:modemmanager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_t:s0 tclass=file Apr 6 19:04:30 localhost kernel: [ 12.853454] type=1400 audit(1302131070.562:23): avc: denied { read } for pid=932 comm="bluetoothd" name="run" dev=dm-0 ino=491 scontext=system_u:system_r:bluetooth_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=lnk_file the systemd-tmpfiles one is followed by: systemd-tmpfiles[864]: Failed to create directory /var/lock/subsys: No such file or directory This looks like it blocks the Beta, we really need to get this crap sorted out :/
Is /run a link file labeled var_t?
Why is /run/udev/data/c4:64 labeled default_t? Who created this directory?
Dan, that's udev in initramfs usually. But we actually do iterate over it in systemd now, and relabel. No clue what this might be...
Any chance your path is screwed up? matchpathcon /run/udev/data/c4:64 /run/udev/data/c4:64 system_u:object_r:udev_var_run_t:s0 As opposed to matchpathcon /udev/data/c4:64 /udev/data/c4:64 system_u:object_r:default_t:s0
dan: not sure who that was aimed at. michich asked me for a few things: matchpathcon /run gives "/run system_u:object_r:var_run_t:s0" and ls -dZ /run gives the same (when booted on the offending image with enforcing=0), so that matches up. I'm uploading the image to my server for you guys to look at. I'll email you the URL since I can't take a lot of traffic, please just dl it once and let me know when you all have it :)
random shot in the dark: could this be due to not having a dracut adjusted for the /run change? that dracut won't make it into beta as things stand, so i intentionally did not include it in the build. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Could be. /run has been a huge pain for SELinux. If things are not labeled correctly SELinux will throw up all over the boot.
My current theory: /run has a wrong label on the root filesystem. This will even prevent systemd to do lstat("/run") in path_is_mount_point(). mount_one() would skip fixing the label in this case...
tried building with the latest dracut available and it still fails, so that guess wasn't a good 'un. I'm a bit stuck for ideas, now.
I downloaded Adam's live image. /run seems to be labeled fine (var_run_t). inode #491 is /var/run which is a symlink: lrwxrwxrwx. root root unconfined_u:object_r:var_t:SystemLow run -> ../run I thought it was not supposed to be a symlink until Fedora 16. In Fedora 15 it should be a bind mount. The symlink is %ghost-ed by filesystem and it is created in its %post scriptlet: %post -p <lua> posix.symlink("../run", "/var/run") posix.symlink("../run/lock", "/var/lock") It would be safer if filesystem kept /var/run as a normal directory (where /run would be bind-mounted on) for F15.
I did notice that filesystem mkdirs it, and *then* creates it as a symlink. That seemed odd, but then, I'm no filesystem ninja and figured it was necessary for some reason.
It is a symlink on new installs, a bind mount on upgrades. On F16 we want to try to even make upgrades get a symlink in place.
So we have two options: 1) enhance the SELinux policy to allow /var/run to be a symlink. I don't know how big change it would be. Dan? 2) remove the trick in filesystem that makes /var/run a symlink on new installs. Make it always a directory in F15. I like the simplicity of this option.
Lennart you have to tell me these things...
Hopefully this is fixed in selinux-policy-3.9.16-13.fc15
(In reply to comment #14) > Lennart you have to tell me these things... Uh, sorry for that. I wasn't actually planning to do this, but others did and it's in filesystem now, and I actually like it. Sorry for not pinging you about this.
thanks, will test quick.
I don't see a -13 build for f15, only f16 - can dan or miroslav please fire a build through and submit it as an update? thanks!
Miroslav should have a building going soon.
btw, I rather like mschmidt's option #2 as well. one of the arguments in favor of putting this change into f15 late was 'well, we're not making /var/run a symlink, so it's not really a major change anyway', remember...
selinux-policy-3.9.16-13.fc15 has been submitted for testing.
With selinux-policy-3.9.16-13.fc15, my freshly installed systems boot without error into firstboot. The issue I was experiencing with fresh installs of -12 seems to be resolved.
Discussed during the 2011-04-08 blocker review meeting [1]. AcceptedBlocker. Prevented system boot after installation. Verified and fixed in RC1 [1] http://meetbot.fedoraproject.org/fedora-bugzappers/2011-04-08/f-15-beta-blocker-review.2011-04-08-17.00.html
The update has been pushed stable, closing.