Bug 835867 - systemd-journald is running as kernel_t
systemd-journald is running as kernel_t
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
AcceptedBlocker
: Reopened
: 835845 835981 (view as bug list)
Depends On:
Blocks: F18Alpha/F18AlphaBlocker
  Show dependency treegraph
 
Reported: 2012-06-27 06:46 EDT by Miroslav Grepl
Modified: 2012-08-16 15:14 EDT (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 15:14:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
boot log (90.58 KB, text/plain)
2012-07-03 13:31 EDT, Nicolas Mailhot
no flags Details
dmesg (279.95 KB, text/plain)
2012-07-31 14:25 EDT, Nicolas Mailhot
no flags Details
system logs (172.95 KB, text/plain)
2012-07-31 14:26 EDT, Nicolas Mailhot
no flags Details
boot avcs (3.70 KB, text/plain)
2012-07-31 14:27 EDT, Nicolas Mailhot
no flags Details

  None (edit)
Description Miroslav Grepl 2012-06-27 06:46:32 EDT
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?
Comment 1 Miroslav Grepl 2012-06-27 06:58:00 EDT
*** Bug 835845 has been marked as a duplicate of this bug. ***
Comment 2 Michal Schmidt 2012-06-27 11:27:16 EDT
The important change is that systemd-journald is now started from the initramfs.
Comment 3 Miroslav Grepl 2012-06-28 04:32:13 EDT
*** Bug 835981 has been marked as a duplicate of this bug. ***
Comment 4 Miroslav Grepl 2012-06-28 07:52:00 EDT
So we are not able to get a proper domain for systemd-journald simply.
Comment 5 Lennart Poettering 2012-06-28 09:52:07 EDT
(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.
Comment 6 Harald Hoyer 2012-07-03 04:50:34 EDT
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?
Comment 7 Miroslav Grepl 2012-07-03 05:34:24 EDT
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
Comment 8 Nicolas Mailhot 2012-07-03 13:31:26 EDT
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
Comment 9 Harald Hoyer 2012-07-05 08:49:04 EDT
not much dracut can.. maybe systemd has to relabel /run after it enabled selinux?
Comment 10 Harald Hoyer 2012-07-05 08:56:49 EDT
you might want to add "rd.systemd.log_level=debug systemd.log_level=debug" to the kernel command line
Comment 11 Nicolas Mailhot 2012-07-08 05:41:35 EDT
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)
Comment 12 Harald Hoyer 2012-07-09 12:08:04 EDT
(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
Comment 13 Jens Petersen 2012-07-30 00:56:37 EDT
systemd storage subsystem still failing to start for me with
latest rawhide.  (Turning off selinux avoids all the errors.)
Comment 14 Daniel Walsh 2012-07-30 09:11:46 EDT
Jens what AVC's are you seeing?
Comment 15 Nicolas Mailhot 2012-07-30 10:56:29 EDT
(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)
Comment 16 Daniel Walsh 2012-07-31 11:27:17 EDT
Fixed in selinux-policy-3.11.0-15.fc18
Comment 17 Nicolas Mailhot 2012-07-31 14:25:13 EDT
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
Comment 18 Nicolas Mailhot 2012-07-31 14:25:52 EDT
Created attachment 601558 [details]
dmesg
Comment 19 Nicolas Mailhot 2012-07-31 14:26:26 EDT
Created attachment 601559 [details]
system logs
Comment 20 Nicolas Mailhot 2012-07-31 14:27:09 EDT
Created attachment 601560 [details]
boot avcs
Comment 21 Nicolas Mailhot 2012-07-31 14:37:46 EDT
(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

(
Comment 22 Jens Petersen 2012-08-01 02:17:09 EDT
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.
Comment 23 Harald Hoyer 2012-08-01 11:22:01 EDT
(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-)
Comment 24 Michal Schmidt 2012-08-01 12:42:02 EDT
My guess is "udev-configure-printer" from system-config-printer. Don't ask me what it does.
Comment 25 Daniel Walsh 2012-08-01 14:56:44 EDT
These avcs do not seem related.  Why would loadkeys need sys_admin? Also why would loadkeys prevent boot?
Comment 26 Daniel Walsh 2012-08-01 14:58:16 EDT
Nicolas

Can you execute 

semanage permissive -a loadkeys_t

And then see if you can boot.
Comment 27 Miroslav Grepl 2012-08-02 04:50:40 EDT
Nicolas,
also try to test the latest F18 build.
Comment 28 Adam Williamson 2012-08-03 13:25:41 EDT
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.
Comment 29 Adam Williamson 2012-08-03 19:47:15 EDT
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!
Comment 30 Miroslav Grepl 2012-08-06 04:10:52 EDT
I am able to boot with enforcing mode wiht 3.11.1 or later. But let's wait for others to confirm it too.
Comment 31 Lennart Poettering 2012-08-10 08:28:21 EDT
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?
Comment 32 Adam Williamson 2012-08-10 13:43:06 EDT
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.
Comment 33 Daniel Walsh 2012-08-13 15:47:55 EDT
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.
Comment 34 Adam Williamson 2012-08-16 12:15:29 EDT
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.
Comment 35 Daniel Walsh 2012-08-16 13:54:03 EDT
Yes I agree that it is fixed.
Comment 36 Adam Williamson 2012-08-16 15:14:46 EDT
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.

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