Bug 2279923 - selinux denials for systemd 256: denied { create } for pid=773 comm="systemd-machine" name="machine" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=0
Summary: selinux denials for systemd 256: denied { create } for pid=773 comm="system...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2280399 2280401 2280479 2280933 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-05-09 20:34 UTC by Adam Williamson
Modified: 2024-05-22 01:27 UTC (History)
12 users (show)

Fixed In Version: selinux-policy-40.20-1.fc40
Clone Of:
Environment:
Last Closed: 2024-05-22 01:27:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 2114 0 None Draft Label systemd configuration files with systemd_conf_t 2024-05-10 10:28:22 UTC

Internal Links: 2290887

Description Adam Williamson 2024-05-09 20:34:03 UTC
the systemd 256 update for Fedora Rawhide is blocked on a failed test which seems to be caused by an SELinux denial. It's the test that all services start correctly. the systemd-machined.service service is failed, and in the logs, we see this:

May 09 04:18:46 fedora systemd[1]: Starting systemd-machined.service - Virtual Machine and Container Registration Service...
May 09 04:18:46 fedora audit[773]: AVC avc:  denied  { create } for  pid=773 comm="systemd-machine" name="machine" scontext=system_u:system_r:systemd_machined_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=dir permissive=0
May 09 04:18:46 fedora systemd-machined[773]: Failed to bind to varlink socket: No such file or directory
May 09 04:18:46 fedora systemd-machined[773]: Failed to fully start up daemon: No such file or directory
May 09 04:18:46 fedora systemd[1]: systemd-machined.service: Main process exited, code=exited, status=1/FAILURE
May 09 04:18:46 fedora systemd[1]: systemd-machined.service: Failed with result 'exit-code'.
May 09 04:18:46 fedora systemd[1]: Failed to start systemd-machined.service - Virtual Machine and Container Registration Service.
May 09 04:18:46 fedora audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-machined comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

I suspect this is caused by this recent systemd change: https://github.com/systemd/systemd/pull/32709

Comment 1 Adam Williamson 2024-05-10 06:16:07 UTC
Specifically, commit https://github.com/systemd/systemd/commit/5b44c81ff868a4d1b78a74e4770f7a8b2f1d0f91 triggers this.

Comment 2 Zdenek Pytela 2024-05-10 07:50:20 UTC
I can confirm the following denials audited:

type=PROCTITLE msg=audit(05/10/2024 03:43:02.391:77) : proctitle=/usr/lib/systemd/systemd-logind 
type=PATH msg=audit(05/10/2024 03:43:02.391:77) : item=0 name=/usr/lib/systemd/logind.conf inode=328890 dev=00:20 mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:init_exec_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=SYSCALL msg=audit(05/10/2024 03:43:02.391:77) : arch=x86_64 syscall=openat success=yes exit=6 a0=AT_FDCWD a1=0x563415516910 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=1065 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/usr/lib/systemd/systemd-logind subj=system_u:system_r:systemd_logind_t:s0 key=(null) 
type=AVC msg=audit(05/10/2024 03:43:02.391:77) : avc:  denied  { open } for  pid=1065 comm=systemd-logind path=/usr/lib/systemd/logind.conf dev="sda3" ino=328890 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 
type=AVC msg=audit(05/10/2024 03:43:02.391:77) : avc:  denied  { read } for  pid=1065 comm=systemd-logind name=logind.conf dev="sda3" ino=328890 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 
----
type=PROCTITLE msg=audit(05/10/2024 03:43:02.391:78) : proctitle=/usr/lib/systemd/systemd-logind 
type=SYSCALL msg=audit(05/10/2024 03:43:02.391:78) : arch=x86_64 syscall=fstat success=yes exit=0 a0=0x6 a1=0x7ffe0ed07550 a2=0x5634152b22c0 a3=0x0 items=0 ppid=1 pid=1065 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/usr/lib/systemd/systemd-logind subj=system_u:system_r:systemd_logind_t:s0 key=(null) 
type=AVC msg=audit(05/10/2024 03:43:02.391:78) : avc:  denied  { getattr } for  pid=1065 comm=systemd-logind path=/usr/lib/systemd/logind.conf dev="sda3" ino=328890 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 
----
type=PROCTITLE msg=audit(05/10/2024 03:43:02.391:79) : proctitle=/usr/lib/systemd/systemd-logind 
type=SYSCALL msg=audit(05/10/2024 03:43:02.391:79) : arch=x86_64 syscall=ioctl success=no exit=ENOTTY(Inappropriate ioctl for device) a0=0x6 a1=TCGETS a2=0x7ffe0ed07380 a3=0x4 items=0 ppid=1 pid=1065 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=systemd-logind exe=/usr/lib/systemd/systemd-logind subj=system_u:system_r:systemd_logind_t:s0 key=(null) 
type=AVC msg=audit(05/10/2024 03:43:02.391:79) : avc:  denied  { ioctl } for  pid=1065 comm=systemd-logind path=/usr/lib/systemd/logind.conf dev="sda3" ino=328890 ioctlcmd=TCGETS scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_exec_t:s0 tclass=file permissive=1 

which is probably just a consequence of:
f41# ls -lZ /usr/lib/systemd/logind.conf
-rw-r--r--. 1 root root system_u:object_r:init_exec_t:s0 1710 May  7 20:00 /usr/lib/systemd/logind.conf

Comment 3 Zdenek Pytela 2024-05-10 10:28:22 UTC
I believe it is an effect of relocation of config files along with

https://github.com/systemd/systemd/blob/main/NEWS
    CHANGES WITH 256-rc1:
    General Changes and New Features:
    
            * Various programs will now attempt to load the main configuration file
              from locations below /usr/lib/, /usr/local/lib/, and /run/, not just
              below /etc/. For example, systemd-logind will look for
              /etc/systemd/logind.conf, /run/systemd/logind.conf,
              /usr/local/lib/systemd/logind.conf, and /usr/lib/systemd/logind.conf,
              and use the first file that is found.  This means that the search
              logic for the main config file and for drop-ins is now the same.

Comment 4 Zdenek Pytela 2024-05-10 10:45:33 UTC
The copr build attached to the PR seems to fix this particular problem, but can bring new ones to other services which possibly need to read those config files.

Comment 5 Adam Williamson 2024-05-10 15:14:34 UTC
Zdenek: are you sure the fix is relevant to the denial that actually causes problems for systemd-machined ?

The commit I linked to - https://github.com/systemd/systemd/commit/5b44c81ff868a4d1b78a74e4770f7a8b2f1d0f91 - makes systemd create and then bind to a /run/systemd/machine/io.systemd.Machine , which doesn't seem related to anything you fixed in the PR. It looks like it would fix the other denials you saw, but not the one I reported.

Comment 6 Zdenek Pytela 2024-05-10 16:26:14 UTC
You are right, I resolved a different issue just because it manisfested right away on a clean system and I misread the reported data which looked similar at first glance.

Comment 7 Zdenek Pytela 2024-05-10 20:38:46 UTC
The github PR now contains 3 independent commits; the advantage should be the automatically created copr build addressing all of known issues.

I will merge those which improve the current state.

Comment 8 Zdenek Pytela 2024-05-15 08:11:26 UTC
*** Bug 2280479 has been marked as a duplicate of this bug. ***

Comment 9 Zdenek Pytela 2024-05-17 17:51:46 UTC
*** Bug 2280401 has been marked as a duplicate of this bug. ***

Comment 10 Zdenek Pytela 2024-05-17 17:52:41 UTC
*** Bug 2280933 has been marked as a duplicate of this bug. ***

Comment 11 Zdenek Pytela 2024-05-17 17:54:04 UTC
*** Bug 2280399 has been marked as a duplicate of this bug. ***

Comment 12 Fedora Update System 2024-05-18 12:14:25 UTC
FEDORA-2024-57abd84015 (selinux-policy-40.19-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-57abd84015

Comment 13 Fedora Update System 2024-05-19 03:01:41 UTC
FEDORA-2024-57abd84015 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-57abd84015`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-57abd84015

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Fedora Update System 2024-05-21 02:22:00 UTC
FEDORA-2024-8c0636295a has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8c0636295a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8c0636295a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 15 Fedora Update System 2024-05-22 01:27:44 UTC
FEDORA-2024-8c0636295a (selinux-policy-40.20-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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