Really weird SELinux denial on boot - rootkit?

Ask Fedora
,
1

Hi. I’m getting a really weird SELinux couple of denials upon boot to a new fresh installation of Fedora 39. I have not seen anything like this when I installed F39 or earlier on the very same machine before under a slightly different setup. The behavior is also different on this installation, more robust I would say. It’s asking for a DAC override?! For real? That’s disabling access controls. There’s also nothing like that (.#hwdb.bin5fda…) in /etc/udev/ folder. Who and what is asking for what in this??

Here’s the entire ausearch -m avc:

time->Sat Dec 16 15:29:33 2023
type=PROCTITLE msg=audit(1702718973.607:89): proctitle=73797374656D642D6877646200757064617465
type=PATH msg=audit(1702718973.607:89): item=2 name=“/etc/udev/.#hwdb.bin5fda7762287eba32” inode=122782 dev=00:1f mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:systemd_hwdb_etc_t:s0 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1702718973.607:89): item=1 name=“/proc/self/fd/3” inode=122782 dev=00:1f mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:systemd_hwdb_etc_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1702718973.607:89): item=0 name=“/etc/udev/” inode=69543 dev=00:1f mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1702718973.607:89): cwd=“/”
type=SYSCALL msg=audit(1702718973.607:89): arch=c000003e syscall=265 success=yes exit=0 a0=ffffff9c a1=7fff960997f0 a2=ffffff9c a3=555e981710e0 items=3 ppid=1 pid=967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=“systemd-hwdb” exe=“/usr/bin/systemd-hwdb” subj=system_u:system_r:systemd_hwdb_t:s0 key=(null)
type=AVC msg=audit(1702718973.607:89): avc: denied { dac_override } for pid=967 comm=“systemd-hwdb” capability=1 scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=system_u:system_r:systemd_hwdb_t:s0 tclass=capability permissive=0

time->Sat Dec 16 15:29:33 2023
type=PROCTITLE msg=audit(1702718973.607:90): proctitle=73797374656D642D6877646200757064617465
type=PATH msg=audit(1702718973.607:90): item=3 name=“/etc/udev/hwdb.bin” inode=120248 dev=00:1f mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:etc_t:s0 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1702718973.607:90): item=2 name=“/etc/udev/.#hwdb.bin5fda7762287eba32” inode=122782 dev=00:1f mode=0100444 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:systemd_hwdb_etc_t:s0 nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1702718973.607:90): item=1 name=“/etc/udev/” inode=69543 dev=00:1f mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=PATH msg=audit(1702718973.607:90): item=0 name=“/etc/udev/” inode=69543 dev=00:1f mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1702718973.607:90): cwd=“/”
type=SYSCALL msg=audit(1702718973.607:90): arch=c000003e syscall=264 success=no exit=-13 a0=ffffff9c a1=555e981710e0 a2=ffffff9c a3=555e98171030 items=4 ppid=1 pid=967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=“systemd-hwdb” exe=“/usr/bin/systemd-hwdb” subj=system_u:system_r:systemd_hwdb_t:s0 key=(null)
type=AVC msg=audit(1702718973.607:90): avc: denied { unlink } for pid=967 comm=“systemd-hwdb” name=“hwdb.bin” dev=“dm-1” ino=120248 scontext=system_u:system_r:systemd_hwdb_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

2

I filed a bug Bug 2254815 - DAC override request from unknown source because this seems some sort of a security vulnerability to me that can be costing people lives. There should be nothing requesting full abrogation of DAC from systemd and hardware related I think. It’s suspicious at the very least.

3

That’s just a temporary file created by systemd-hwdb (tmpfn_random()) to update the hwdb atomically.

I’m not an SELinux expert, but I think a dac_override denial usually just means permissions are set incorrectly. Normally, root can access any file, but SELinux blocks that by default.

Please share:

ls -ldZ / /etc /etc/udev /etc/udev/hwdb.bin
1 Like
4

Whew I guess. The context on /etc/udev/hwdb.bin is unconfined_u:object_r:etc_t:s0 versus I would imagine the needed system_u:… Is that what’s causing the SELinux denial? What gets denied though? Everything is working fine.

5

And also then why would the context change on a default Fedora installation and not get relabed correctly?

6

I’d expect that hwdb.bin isn’t getting updated. Check systemctl status systemd-hwdb-update.

Does restorecon -v /etc/udev/hwdb.bin fix the context? It should be system_u:object_r:systemd_hwdb_etc_t:s0. Also, the unconfined_u doesn’t seem to matter. systemd-hwdb is apparently restricted to accessing files of type systemd_hwdb_etc_t within /etc.

I don’t know how this would have happened unless you booted with SELinux disabled. I’m assuming you would have mentioned that.

7

systemd-hwdb-update is inactive and the hw db rebuilding was skipped it says.
Why would I want to fix the context now? It seems to boot normal the way it is. Is there a point to fix the context and have the hwdb rebuilt?

I have NOT booted with SELinux disabled. Does booting the system in an nspawn container count? That would keep SELinux off.

8

What would even try to update the hwdb? It says that updating hwdb is needed only if you need specific behavior from a device – and none are needed as far as I know, never had to update it. And systemd-udev package ships with a hwdb.bin file already (not sure if it gets rebuilt during install).

9 
$ systemctl cat systemd-hwdb-update.service 
# /usr/lib/systemd/system/systemd-hwdb-update.service
[...]
ConditionNeedsUpdate=/etc
ConditionPathExists=|!/usr/lib/udev/hwdb.bin
ConditionPathExists=|/etc/udev/hwdb.bin
ConditionDirectoryNotEmpty=|/etc/udev/hwdb.d/
[...]

The service runs if the first condition is met (/usr is newer than /etc, basically), along with at least one of the last three. Because Fedora puts hwdb.bin in /etc, two of those are met, and the first should be met on first boot and any time /usr’s mtime changes.

To be honest, I’m not sure why the hwdb isn’t in /usr.

Regardless, the hwdb is updated the same way (systemd-hwdb update) in an rpm file trigger, and that would likely fail for the same reason. In fact, that may be where the error is happening for you. The systemd-udev package itself uses udevadm hwdb --update, which probably isn’t similarly confined, but that doesn’t help for hwdb.d entries installed by other packages.

10

I’m not sure why this is either. I read that if you ship hwdb.bin you leave it in /usr, if you actively customize hwdb you then work with /etc. Why is Fedora putting hwdb.bin into /etc??

I guess this is concerning to me from the security point of view. I don’t want the hwdb be changed on boot and have behavior of my pretty important devices (including serial devices like an inbuilt keyboard) be customized without me asking for it specifically. Am I right to be concerned about this?

12

Looks similar to
https://bugzilla.redhat.com/show_bug.cgi?id=2240221
which seems to be a kernel bug.

13

It’s similar but might be different still. I added info at the link you provided.