FEDORA-2024-57abd84015 — bugfix update for selinux-policy

obsolete

selinux-policy-40.19-1.fc40

FEDORA-2024-57abd84015 created by zpytela a year ago for Fedora 40

New F40 selinux-policy build

This update has been submitted for testing by zpytela.

a year ago

This update's test gating status has been changed to 'waiting'.

a year ago

This update's test gating status has been changed to 'waiting'.

a year ago

This update's test gating status has been changed to 'failed'.

a year ago

adamwill commented & provided feedback a year ago

karma

This seems to be denying systemd-resolved, which breaks FreeIPA DNS:

time->Sat May 18 07:05:44 2024
type=PROCTITLE msg=audit(1716030344.500:53): proctitle="/usr/lib/systemd/systemd-resolved"
type=PATH msg=audit(1716030344.500:53): item=0 name="." inode=715865 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:systemd_conf_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1716030344.500:53): cwd="/"
type=SYSCALL msg=audit(1716030344.500:53): arch=c000003e syscall=257 success=no exit=-13 a0=7 a1=7f554f13a438 a2=b0800 a3=0 items=1 ppid=1 pid=727 auid=4294967295 uid=193 gid=193 euid=193 suid=193 fsuid=193 egid=193 sgid=193 fsgid=193 tty=(none) ses=4294967295 comm="systemd-resolve" exe="/usr/lib/systemd/systemd-resolved" subj=system_u:system_r:systemd_resolved_t:s0 key=(null)
type=AVC msg=audit(1716030344.500:53): avc:  denied  { read } for  pid=727 comm="systemd-resolve" name="resolved.conf.d" dev="dm-0" ino=715865 scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:systemd_conf_t:s0 tclass=dir permissive=0

The results look consistent across this and the F41 update, on openQA prod and stg, so I think it's a real bug.

This update has been pushed to testing.

a year ago

Bodhi is disabling automatic push to stable due to negative karma. The maintainer may push manually if they determine that the issue is not severe.

a year ago

bojan commented a year ago

Works here, but given previous -1, not going to claim more than this. I am running systemd-resolved on one of the machines and didn't notice any denials (yet).

bojan commented & provided feedback a year ago

Tried on another machine (gnome desktop VM) and did not see the denials either. Systemd-resolved definitely running.

nixuser commented & provided feedback a year ago

I'm not seeing any alerts either (after a reboot) and systemd-resolved is definitely running.

adama$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2024-05-19 15:37:32 AEST; 28s ago

g6avk commented & provided feedback a year ago

karma

Looks OK on this box as well, no alerts:

....$ systemctl status systemd-resolved
* systemd-resolved.service - Network Name Resolution
Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
Drop-In: /usr/lib/systemd/system/service.d
└─10-timeout-abort.conf
Active: active (running) since Sun 2024-05-19 08:45:50 BST; 1h 11min ago

py0xc3 commented & provided feedback a year ago

karma

I tested on Fedora 40 KDE within a QEMU/KVM (cpu-passthrough with AMD Ryzen 7 PRO 6850U). Up to date with updates-testing repo as of now (kernel 6.8.10). I tested with a user account that is confined with user_u (__default__ = user_u): firefox, dolphin, terminal worked fine. Login & logout in KDE worked as expected as well. Denials are logged but I expect they are related to confinement: if I compare to the previous boot before the selinux-policy-40.19-1.fc40 update, I can verify that all denials that are now logged occurred before this update as well as far as it concerns root sessions (root = unconfined_u). I cannot compare the desktop denials (user_u) since I was not using the desktop on this testing VM before, but as already mentioned, the user_u GUI worked fine, but for the record, here are the denials that have been logged when I was logged in with user_u GUI - these are denials at which I do not know if they had occurred before because previous boots on that VM did not contain GUI sessions:

type=AVC msg=audit(05/19/2024 21:17:17.771:327) : avc:  denied  { watch } for  pid=2961 comm=dolphin path=/etc/abrt dev="vda3" ino=299 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir permissive=0 
----
type=AVC msg=audit(05/19/2024 21:17:17.771:328) : avc:  denied  { watch } for  pid=2961 comm=dolphin path=/etc/abrt dev="vda3" ino=299 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir permissive=0 
----
type=AVC msg=audit(05/19/2024 21:17:29.986:335) : avc:  denied  { watch } for  pid=1856 comm=drkonqi-coredum path=/run/log/journal dev="tmpfs" ino=64 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:syslogd_var_run_t:s0 tclass=dir permissive=0 
----
type=AVC msg=audit(05/19/2024 21:17:43.749:350) : avc:  denied  { watch } for  pid=3198 comm=systemd path=/var dev="vda3" ino=277 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0

With regards to above posts:

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2024-05-19 21:25:00 CEST; 6min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 774 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9483)
     Memory: 5.6M (peak: 6.2M)
        CPU: 142ms
     CGroup: /system.slice/systemd-resolved.service
             └─774 /usr/lib/systemd/systemd-resolved

py0xc3 commented & provided feedback a year ago

Sorry, correction to my above post, please ignore the following line:

type=AVC msg=audit(05/19/2024 21:17:43.749:350) : avc:  denied  { watch } for  pid=3198 comm=systemd path=/var dev="vda3" ino=277 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0

-> This one has occurred before and is not related to the GUI session

zpytela commented & provided feedback a year ago

I think the issue with systemd services manifests only if there are changes to default config files, so majority of users is not affected. Anyway there will be a new build tomorrow because the current one brings a regression.

For new and unrelated problems, please file a bug.

This update has been obsoleted by selinux-policy-40.20-1.fc40.

a year ago

Please log in to add feedback.

Metadata

Type

bugfix

Severity

medium

Karma

Signed

Content Type

RPM

Test Gating

failed

Autopush Settings

Unstable by Karma

-2

Stable by Karma

disabled

Stable by Time

disabled

Thresholds

Minimum Karma

Minimum Testing

14 days

Dates

submitted

a year ago

in testing

a year ago

Builds

selinux-policy-40.19-1.fc40

BZ#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

BZ#2280017 SELinux is preventing nfsidmap from connectto access on the unix_stream_socket /run/systemd/userdb/io.systemd.Home.

selinux-policy-40.19-1.fc40

Automated Test Results

For help debugging failed Fedora CI tests (fedora-ci.*), contact the Fedora CI team.
For help debugging failed Fedora CoreOS tests (coreos.*), contact the Fedora CoreOS team.
For help debugging failed openQA tests (update.*), contact the Fedora Quality team, who will usually investigate and diagnose all failures within 24 hours.

failed