Description of problem: system_u:system_r:kernel_t:s0 286 ? Ss 0:00 /usr/lib/systemd/systemd-journald So I am getting a lot AVC msgs. How is systemd-journald now started?
*** Bug 835845 has been marked as a duplicate of this bug. ***
The important change is that systemd-journald is now started from the initramfs.
*** Bug 835981 has been marked as a duplicate of this bug. ***
So we are not able to get a proper domain for systemd-journald simply.
(In reply to comment #4) > So we are not able to get a proper domain for systemd-journald simply. Hmm, it should actually be terminated in the initrd and then a new instance hsould take over in the host system.
Still an issue? I see this: # journalctl -a | grep systemd-journal Jul 03 09:10:40 localhost systemd-journal[88]: Journal started Jul 03 09:10:41 localhost systemd-journal[88]: Journal stopped Jul 03 09:10:41 localhost systemd-journal[279]: Journal started What is your kernel command line?
With updated F18 # journalctl -a | grep systemd-journal Jul 03 11:23:13 localhost systemd-journal[55]: Journal started Jul 03 11:23:18 localhost systemd-journal[55]: Journal stopped Jul 03 11:23:18 localhost systemd-journal[223]: Journal started # ps -efZ |grep systemd-journald system_u:system_r:kernel_t:s0 root 223 1 0 11:23 ? 00:00:00 /usr/lib/systemd/systemd-journald /vmlinuz-3.5.0-0.rc4.git4.1.fc18.x86_64 root=UUID=aa2d1710-c0b6-402e-91c2-be9938ff7c49 ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 rhgb quiet
Created attachment 596057 [details] boot log Yes very much still an issue dracut-020-22.git20120702.fc18.x86_64 dracut-tools-020-22.git20120702.fc18.x86_64 kernel-3.5.0-0.rc5.git0.2.fc18.x86_64 kernel-headers-3.5.0-0.rc5.git0.2.fc18.x86_64 kernel-tools-3.5.0-0.rc5.git0.2.fc18.x86_64 selinux-policy-3.11.0-7.fc18.noarch selinux-policy-devel-3.11.0-7.fc18.noarch selinux-policy-doc-3.11.0-7.fc18.noarch selinux-policy-targeted-3.11.0-7.fc18.noarch systemd-185-7.gite7aee75.fc18.x86_64 systemd-analyze-185-7.gite7aee75.fc18.x86_64 systemd-libs-185-7.gite7aee75.fc18.x86_64 systemd-sysv-185-7.gite7aee75.fc18.x86_64
not much dracut can.. maybe systemd has to relabel /run after it enabled selinux?
you might want to add "rd.systemd.log_level=debug systemd.log_level=debug" to the kernel command line
Anyway further dracut/systemd updates not only didn't resolve the problem, but bricked the system (new kernels didn't boot - unknown block device and older 'safe' kernels with previously-generated initramfs couldn't pivot root properly anymore ) This is exceptionally bad producing broken setups happens but breaking the fallback is wrong. Please be more careful I've reinstalled a new F17 system and updated to rawhide except for dracut-019-2.fc18.noarch libgudev1-185-1.fc18.x86_64 systemd-185-1.fc18.x86_64 systemd-sysv-185-1.fc18.x86_64 And this combo works without strange systemd journal selinux problems, without pivot-root problems and without block device errors I don't intend to do further testing of this bug before someone confirms systemd and dracut are safe to upgrade (one day reinstall is enough)
(In reply to comment #11) > Anyway further dracut/systemd updates not only didn't resolve the problem, > but bricked the system (new kernels didn't boot - unknown block device and > older 'safe' kernels with previously-generated initramfs couldn't pivot root > properly anymore ) > > This is exceptionally bad producing broken setups happens but breaking the > fallback is wrong. Please be more careful > > I've reinstalled a new F17 system and updated to rawhide except for > dracut-019-2.fc18.noarch > libgudev1-185-1.fc18.x86_64 > systemd-185-1.fc18.x86_64 > systemd-sysv-185-1.fc18.x86_64 > > And this combo works without strange systemd journal selinux problems, > without pivot-root problems and without block device errors > > I don't intend to do further testing of this bug before someone confirms > systemd and dracut are safe to upgrade (one day reinstall is enough) tomorrow will be safe
systemd storage subsystem still failing to start for me with latest rawhide. (Turning off selinux avoids all the errors.)
Jens what AVC's are you seeing?
(In reply to comment #14) > Jens what AVC's are you seeing? [ 30.086492] type=1400 audit(1343659592.384:3): avc: denied { getattr } for pid=398 comm="systemd-journal" path="socket:[5887]" dev="sockfs" ino=5887 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket [ 74.758714] type=1400 audit(1343659637.056:4): avc: denied { write } for pid=613 comm="systemd-tmpfile" name="socket" dev="tmpfs" ino=5891 scontext=system_u:system_r:systemd_tmpfiles_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=sock_file dracut-022-63.git20120727.fc18.x86_64 kernel-3.6.0-0.rc0.git2.1.fc18.x86_64 selinux-policy-3.11.0-13.fc18.noarch selinux-policy-devel-3.11.0-13.fc18.noarch selinux-policy-targeted-3.11.0-13.fc18.noarch systemd-187-3.fc18.x86_64 systemd-libs-187-3.fc18.x86_64 booting with enforcing=0 (else noboot as Jens stated)
Fixed in selinux-policy-3.11.0-15.fc18
Still not working; had to provide admin password and start the gpm service manually to get the boot process to proceed in enforcing mode dracut-022-99.git20120730.fc18.x86_64 kernel-3.6.0-0.rc0.git4.1.fc18.x86_64 selinux-policy-3.11.0-15.fc18.noarch selinux-policy-devel-3.11.0-15.fc18.noarch selinux-policy-targeted-3.11.0-15.fc18.noarch systemd-187-3.fc18.x86_64 systemd-libs-187-3.fc18.x86_64 systemd-sysv-187-3.fc18.x86_64
Created attachment 601558 [details] dmesg
Created attachment 601559 [details] system logs
Created attachment 601560 [details] boot avcs
(the logs show the manual intervention after two minutes of failed boot, and the storage target failure before like Jens reported [ 69.927339] systemd[1]: Job fedora-storage-init-late.service/start finished, result=failed [ 117.668387] systemd[1]: emergency.service changed start-pre -> running (
Thanks, Nicolas Right, selinux-policy-3.11.0-15.fc18 (which is in rawhide) doesn't help much for me either - still see journald and storage subsystem failures from systemd too.
(In reply to comment #18) > Created attachment 601558 [details] > dmesg what the heck is this? [ 34.151507] systemd[1]: Received SIGCHLD from PID 514 (udev-configure-). [ 34.152745] systemd[1]: Got SIGCHLD for process 513 (udev-configure-) [ 34.154118] systemd[1]: Child 513 died (code=exited, status=1/FAILURE) [ 34.154502] systemd[1]: Got SIGCHLD for process 514 (udev-configure-)
My guess is "udev-configure-printer" from system-config-printer. Don't ask me what it does.
These avcs do not seem related. Why would loadkeys need sys_admin? Also why would loadkeys prevent boot?
Nicolas Can you execute semanage permissive -a loadkeys_t And then see if you can boot.
Nicolas, also try to test the latest F18 build.
Please re-test with selinux-policy 3.11.1 or later; I found 3.11.0-* gave me a non-bootable system with various AVCs, but 3.11.1 works fine.
Discussed at the blocker bug review meeting of 2012-08-03: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-08-03/f18-alpha-blocker-review-1.2012-08-03-17.01.log.html . Accepted as a blocker for the 'system fails to boot without intervention' consequences - violates Alpha criterion "Following on from the previous criterion, after firstboot is completed and on subsequent boots, 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 a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied". However, please check with 3.11.1 or later, as I mentioned; if that solves the issues for everyone, we can close this. Thanks!
I am able to boot with enforcing mode wiht 3.11.1 or later. But let's wait for others to confirm it too.
Hmm, so journald since a while shot not be running as kernel_t anymore. However, the syslog and journal sockets are still created in the initrd and thus labelled as kernel_t and then passed on like this to the main system, so that they continue to be labelled kernel_t during the entire runtime. I am not sure what the right fix is here. One option could be to close/reopen the sockets in question during the initrd transition, but that would actually mean that we'd lose queued log messages and is hence really not that desirable. In fact, that we now can collect full logs from the initrd the same way as for the main system is a key feature, and by closing/reopening the sockets we would make this unreliable. Another option could be to just live with the fact that these sockets are labelled kernel_t? Another option could be to include the SELinux policy in the initrd, but that would increase the initrd size quite a bit, and is probably not desriable at all. The best option in my eyes would be if we could relabel open socket fds, so that we can keep the sockets open but still can update the labels on it. Or is there a way how this can already be achieved?
lennart: I don't know the ins and outs, but we're actually reasonably confident 3.11.1 fixes this, and it's just still open because none of the original reporters has confirmed yet.
We have decided to allow all processes that syslog to write to a kernel_t unix_stream_socket. Even if we could change the label of the socket after it was created, we would still have a race condition, where the label would be wrong. This way we keep the socket open. The only potential risk would be that a leaked unix_stream_socket labeled kernel_t can now be written to by processes.
Catching up - this was discussed at the 2012-08-10 blocker review meeting. It looks like it's fixed, but we agreed to wait for more feedback to confirm that before closing.
Yes I agree that it is fixed.
Discussed again at 2012-08-16 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-08-16/f18-alpha-blocker-review-3.2012-08-16-16.00.html . We agreed that experience indicates strongly this is fixed, and there's no point waiting for more feedback any more, we'll just close the bug. It can be re-opened if need be.