Lots of avc denied systemd-journald in journalctl log

Project Discussion
1

Hi,
since my upgrade to Silverblue 30 yesterday, I get a lot of these messages in my journalctl log:

Mai 01 09:32:21 localhost.localdomain audit: PROCTITLE proctitle=“/usr/lib/systemd/systemd-journald”
Mai 01 09:32:21 localhost.localdomain audit[838]: AVC avc: denied { signull } for pid=838 comm=“systemd-journal” scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:system_r:modemmanager_t:s0 tclass=process permissive=0
Mai 01 09:32:21 localhost.localdomain audit[838]: SYSCALL arch=c000003e syscall=62 success=no exit=-13 a0=440 a1=0 a2=ffffffff a3=225462 items=0 ppid=1 pid=838 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=“systemd-journal” exe=“/usr/lib/systemd/systemd-journald” subj=system_u:system_r:syslogd_t:s0 key=(null)

Part of my journalctl -b log can be found here: https://paste.fedoraproject.org/paste/3CTXR9Vy6uYfhg3XiJ8Q4A#

Is there something wrong with my SELinux setup?

2

I’ve been seeing similar denials in my logs, too. I went looking around and found the following:

I found one BZ for the SELinux denials around systemd-modules; it looks like it should be fixed in selinux-policy-3.14.3-29.fc30 (which is included in Silverblue 30.20190427.n.0). Interestingly, I’m running that version and am still experiencing it.

https://bugzilla.redhat.com/show_bug.cgi?id=1697632

For the systemd-journal messages, I found this BZ 1673847 – SELinux is preventing /usr/lib/systemd/systemd-journald from using the 'signull' accesses on a process. filed against Rawhide, which says there is a fix in selinux-policy-3.14.4-8.fc31

I’d expect the next version of selinux-policy built for F30 should include that fix.

3

With the help of @jlebon, I figured out that I had a modified SELinux policy on my host and it appears it was the source of these kinds of SELinux denials (as well as other denials I had seen).

You can see if you are in a similar situation by examining the config-diff on your host to see if your policy has been modified. For example, mine looked like:

$ sudo ostree admin config-diff | grep policy
M    selinux/targeted/active/policy.linked
M    selinux/targeted/active/policy.kern
M    selinux/targeted/policy/policy.31
A    selinux/targeted/policy/policy.30

We first tried to backup the existing SELinux settings and then using rsync to copy over the policy from the ostree commit to /etc/selinux:

$ sudo cp -al /etc/selinux{,.bak}
$ sudo rsync -rlv /usr/etc/selinux/ /etc/selinux/

But modifications were still shown after those operations; (the selinux.bak entries are expected in this case):

$ sudo ostree admin config-diff | grep policy
M    selinux/targeted/active/policy.linked
M    selinux/targeted/active/policy.kern
A    selinux/targeted/policy/policy.30
A    selinux.bak/targeted/active/policy.linked
A    selinux.bak/targeted/active/policy.kern
A    selinux.bak/targeted/active/modules/100/policykit
A    selinux.bak/targeted/active/modules/100/policykit/cil
A    selinux.bak/targeted/active/modules/100/policykit/hll
A    selinux.bak/targeted/active/modules/100/policykit/lang_ext
A    selinux.bak/targeted/.policy.sha512
A    selinux.bak/targeted/policy
A    selinux.bak/targeted/policy/policy.30
A    selinux.bak/targeted/policy/policy.31

The next option was the nuclear option which was to nuke the existing /etc/selinux directory and copy it fresh.

!!! WARNING !!! this could have adverse effects on your host. I take no responsibility for any problems that arise after doing this !!! WARNING !!!

$ sudo rm -rf /etc/selinux
$ sudo cp -aT /usr/etc/selinux /etc/selinux

After doing that, the config-diff showed that my settings were what was expected from the ostree commit (again, in this case the selinux.bak entries are expected):

$ sudo ostree admin config-diff | grep selinux
A    selinux.bak                                                  
A    selinux.bak/final                                        
A    selinux.bak/targeted          
<snip>

I rebooted my host a few times, just to make sure the new SELinux policy was intact and I no longer saw any denials in the journal.

1 Like
4

Deleting the /etc/selinux directory and copy it fresh solved the problem for me, too.
Also my boot times are much shorter now than before.
Thanks for the fix.

1 Like