Bug 835867 - systemd-journald is running as kernel_t
Summary: systemd-journald is running as kernel_t
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 835845 835981 (view as bug list)
Depends On:
Blocks: F18Alpha, F18AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2012-06-27 10:46 UTC by Miroslav Grepl
Modified: 2012-08-16 19:14 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 19:14:46 UTC
Type: Bug


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

Description Miroslav Grepl 2012-06-27 10:46:32 UTC
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 10:58:00 UTC
*** Bug 835845 has been marked as a duplicate of this bug. ***

Comment 2 Michal Schmidt 2012-06-27 15:27:16 UTC
The important change is that systemd-journald is now started from the initramfs.

Comment 3 Miroslav Grepl 2012-06-28 08:32:13 UTC
*** Bug 835981 has been marked as a duplicate of this bug. ***

Comment 4 Miroslav Grepl 2012-06-28 11:52:00 UTC
So we are not able to get a proper domain for systemd-journald simply.

Comment 5 Lennart Poettering 2012-06-28 13:52:07 UTC
(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 08:50:34 UTC
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 09:34:24 UTC
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 17:31:26 UTC
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 12:49:04 UTC
not much dracut can.. maybe systemd has to relabel /run after it enabled selinux?

Comment 10 Harald Hoyer 2012-07-05 12:56:49 UTC
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 09:41:35 UTC
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 16:08:04 UTC
(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 04:56:37 UTC
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 13:11:46 UTC
Jens what AVC's are you seeing?

Comment 15 Nicolas Mailhot 2012-07-30 14:56:29 UTC
(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 15:27:17 UTC
Fixed in selinux-policy-3.11.0-15.fc18

Comment 17 Nicolas Mailhot 2012-07-31 18:25:13 UTC
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 18:25:52 UTC
Created attachment 601558 [details]
dmesg

Comment 19 Nicolas Mailhot 2012-07-31 18:26:26 UTC
Created attachment 601559 [details]
system logs

Comment 20 Nicolas Mailhot 2012-07-31 18:27:09 UTC
Created attachment 601560 [details]
boot avcs

Comment 21 Nicolas Mailhot 2012-07-31 18:37:46 UTC
(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 06:17:09 UTC
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 15:22:01 UTC
(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 16:42:02 UTC
My guess is "udev-configure-printer" from system-config-printer. Don't ask me what it does.

Comment 25 Daniel Walsh 2012-08-01 18:56:44 UTC
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 18:58:16 UTC
Nicolas

Can you execute 

semanage permissive -a loadkeys_t

And then see if you can boot.

Comment 27 Miroslav Grepl 2012-08-02 08:50:40 UTC
Nicolas,
also try to test the latest F18 build.

Comment 28 Adam Williamson 2012-08-03 17:25:41 UTC
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 23:47:15 UTC
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 08:10:52 UTC
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 12:28:21 UTC
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 17:43:06 UTC
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 19:47:55 UTC
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 16:15:29 UTC
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 17:54:03 UTC
Yes I agree that it is fixed.

Comment 36 Adam Williamson 2012-08-16 19:14:46 UTC
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.