Hide Forgot
Description of problem: It just happens with systemd-resolved enabled. systemd-resolved is a system bus daemon, it seems reasonable it accesses /run/dbus SELinux is preventing /usr/lib/systemd/systemd-resolved from 'read' accesses on the directory /run/dbus. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that systemd-resolved should be allowed read access on the dbus directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'systemd-resolve' --raw | audit2allow -M my-systemdresolve # semodule -X 300 -i my-systemdresolve.pp Additional Information: Source Context system_u:system_r:systemd_resolved_t:s0 Target Context system_u:object_r:system_dbusd_var_run_t:s0 Target Objects /run/dbus [ dir ] Source systemd-resolve Source Path /usr/lib/systemd/systemd-resolved Port <Unknown> Host (removed) Source RPM Packages systemd-238-7.fc28.x86_64 Target RPM Packages dbus-1.12.0-1.fc28.x86_64 Policy RPM selinux-policy-3.14.1-19.fc28.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.16.0-300.fc28.x86_64 #1 SMP Tue Apr 3 03:44:37 UTC 2018 x86_64 x86_64 Alert Count 5 First Seen 2018-03-31 17:48:56 PDT Last Seen 2018-04-10 21:21:29 PDT Local ID 02efbf8f-bdd3-4529-b1a9-69ec4198345a Raw Audit Messages type=AVC msg=audit(1523420489.160:102): avc: denied { read } for pid=963 comm="systemd-resolve" name="dbus" dev="tmpfs" ino=23943 scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=dir permissive=0 type=SYSCALL msg=audit(1523420489.160:102): arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES a0=f a1=562c4a16ee60 a2=2000d84 a3=63 items=1 ppid=1 pid=963 auid=4294967295 uid=997 gid=996 euid=997 suid=997 fsuid=997 egid=996 sgid=996 fsgid=996 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=CWD msg=audit(1523420489.160:102): cwd=/ type=PATH msg=audit(1523420489.160:102): item=0 name=/run/dbus inode=23943 dev=00:17 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:system_dbusd_var_run_t:s0 nametype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 Hash: systemd-resolve,systemd_resolved_t,system_dbusd_var_run_t,dir,read Version-Release number of selected component: selinux-policy-3.14.1-19.fc28.noarch Additional info: component: selinux-policy reporter: libreport-2.9.4 hashmarkername: setroubleshoot kernel: 4.16.0-300.fc28.x86_64 type: libreport
Hi, Are you able to reproduce it? Thanks, Lukas.
It still happens (I just got a new notification right now). I cannot reproduce it precisely. Regardless, this does not seem like a difficult bug to diagnose: systemd-resolved is a system bus daemon, hence it needs to access /run/dbus. (On a cursory read it seems it is trying to check if the dbus socket is there, and then set an inotify watch on it - which makes sense, as systemd-resolved needs to be able to survive the system bus disappearing or appearing late during boot) The bug is just in the policy.
Description of problem: This started happening after updating last night. I'm domain joined and have tried getting DNS from both/either RAs and DHCPv6, even entering in manual addresses in network manager does not work (which sould be consistent with resolved not being able to read dbus). Version-Release number of selected component: selinux-policy-3.14.1-21.fc28.noarch Additional info: reporter: libreport-2.9.4 hashmarkername: setroubleshoot kernel: 4.16.3-300.fc28.x86_64 type: libreport
Description of problem: This occurs when running systemd-resolvd in the new FC28 version. No problem in the latest FC27 version. Version-Release number of selected component: selinux-policy-3.14.1-21.fc28.noarch Additional info: reporter: libreport-2.9.4 hashmarkername: setroubleshoot kernel: 4.16.4-300.fc28.x86_64 type: libreport
selinux-policy-3.14.1-25.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d19ffdb4ba
selinux-policy-3.14.1-25.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d19ffdb4ba
selinux-policy-3.14.1-25.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.