Bug 694239 - Live image built with latest systemd/selinux-policy etc fails to boot with selinux enabled
Live image built with latest systemd/selinux-policy etc fails to boot with se...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
Unspecified Unspecified
unspecified Severity urgent
: ---
: ---
Assigned To: Lennart Poettering
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F15Beta/F15BetaBlocker
  Show dependency treegraph
 
Reported: 2011-04-06 15:07 EDT by Adam Williamson
Modified: 2011-04-11 11:18 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-11 11:18:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2011-04-06 15:07:18 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 :/
Comment 1 Daniel Walsh 2011-04-06 16:18:43 EDT
Is /run a link file labeled var_t?
Comment 2 Daniel Walsh 2011-04-06 16:19:39 EDT
Why is /run/udev/data/c4:64 labeled default_t?  Who created this directory?
Comment 3 Lennart Poettering 2011-04-06 16:21:32 EDT
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...
Comment 4 Daniel Walsh 2011-04-06 16:29:21 EDT
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
Comment 5 Adam Williamson 2011-04-06 16:41:39 EDT
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 :)
Comment 6 Adam Williamson 2011-04-06 17:14:59 EDT
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
Comment 7 Daniel Walsh 2011-04-06 17:24:32 EDT
Could be. /run has been a huge pain for SELinux.  If things are not labeled correctly SELinux will throw up all over the boot.
Comment 8 Michal Schmidt 2011-04-06 17:29:24 EDT
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...
Comment 9 Adam Williamson 2011-04-06 22:01:51 EDT
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.
Comment 10 Michal Schmidt 2011-04-07 01:18:07 EDT
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.
Comment 11 Adam Williamson 2011-04-07 01:26:25 EDT
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.
Comment 12 Lennart Poettering 2011-04-07 07:59:45 EDT
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.
Comment 13 Michal Schmidt 2011-04-07 09:12:33 EDT
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.
Comment 14 Daniel Walsh 2011-04-07 10:22:37 EDT
Lennart you have to tell me these things...
Comment 15 Daniel Walsh 2011-04-07 10:30:07 EDT
Hopefully this is fixed in selinux-policy-3.9.16-13.fc15
Comment 16 Lennart Poettering 2011-04-07 11:26:17 EDT
(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.
Comment 17 Adam Williamson 2011-04-07 11:27:28 EDT
thanks, will test quick.
Comment 18 Adam Williamson 2011-04-07 11:37:13 EDT
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!
Comment 19 Daniel Walsh 2011-04-07 11:44:40 EDT
Miroslav should have a building going soon.
Comment 20 Adam Williamson 2011-04-07 11:56:10 EDT
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...
Comment 21 Miroslav Grepl 2011-04-07 14:17:16 EDT
selinux-policy-3.9.16-13.fc15 has been submitted for testing.
Comment 22 James Laska 2011-04-07 15:46:44 EDT
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.
Comment 23 James Laska 2011-04-08 14:48:45 EDT
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
Comment 24 Adam Williamson 2011-04-11 11:18:13 EDT
The update has been pushed stable, closing.

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