Description of problem: After upgrading sssd via dnf upgrade. SELinux is preventing sssd from 'read' accesses on the directory NetworkManager. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sssd should be allowed read access on the NetworkManager 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 'sssd' --raw | audit2allow -M my-sssd # semodule -X 300 -i my-sssd.pp Additional Information: Source Context system_u:system_r:sssd_t:s0 Target Context system_u:object_r:NetworkManager_var_run_t:s0 Target Objects NetworkManager [ dir ] Source sssd Source Path sssd Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.4-49.fc31.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.5.7-200.fc31.x86_64 #1 SMP Fri Feb 28 17:18:37 UTC 2020 x86_64 x86_64 Alert Count 1 First Seen 2020-03-05 08:34:26 CET Last Seen 2020-03-05 08:34:26 CET Local ID 9ca63157-b027-44ae-9a9b-d7f8ca37d1a6 Raw Audit Messages type=AVC msg=audit(1583393666.924:334): avc: denied { read } for pid=6635 comm="sssd" name="NetworkManager" dev="tmpfs" ino=23588 scontext=system_u:system_r:sssd_t:s0 tcontext=system_u:object_r:NetworkManager_var_run_t:s0 tclass=dir permissive=0 Hash: sssd,sssd_t,NetworkManager_var_run_t,dir,read Version-Release number of selected component: selinux-policy-3.14.4-49.fc31.noarch Additional info: component: selinux-policy reporter: libreport-2.12.0 hashmarkername: setroubleshoot kernel: 5.5.7-200.fc31.x86_64 type: libreport
Michal, Does the new version of sssd require to read NetworkManager pid files?
(In reply to Zdenek Pytela from comment #1) > Michal, > > Does the new version of sssd require to read NetworkManager pid files? Maybe NetworkManager creates a link to resolv.conf leading to NetworkManager's own directory? This would explain why SSSD tries to read there. I am not sure though. Maybe NetworkManager maintainers will have an answer to this? Michal
(In reply to Michal Zidek from comment #2) > Maybe NetworkManager creates a link to resolv.conf leading > to NetworkManager's own directory? This would explain why SSSD > tries to read there. Yes, this is the case on my system: $ ls -l /etc/resolv.conf lrwxrwxrwx. 1 root root 35 2019-11-20 12:24 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf Shouldn't pretty much anything be allowed to read resolv.conf? And why would sssd read the *directory* and not just the file?
Similar problem has been detected: Updated to sssd 2.2.3-13 hashmarkername: setroubleshoot kernel: 5.5.5-200.fc31.x86_64 package: selinux-policy-3.14.4-49.fc31.noarch reason: SELinux is preventing sssd from 'read' accesses on the directory NetworkManager. type: libreport
Hi, recent versions of SSSD will follow the sym-links of /etc/resolv.conf to be able to monitor the target file for updates and changes. So I think it is ok to add a SELinux rule for this. Zdenek, do you agree? bye, Sumit
Sumit, Definitely there is no problem with allowing it. Eike, The general approach is to allow a rule only when it is required. In this case though we are solving an access of sssd to NetworkManager runtime directory. To your second question: before accessing a file, all directories in the filesystem hierarchy need to be searched first. Then it is a matter of implementation in the software if the directory is only searched to get access to the file or its whole content is read or even map-read, maybe Sumit/Michal can comment on that. The selinux-policy denied just sssd the access to the NetworkManager runtime directory, the permission to read the resolv.conf file is allowed. See the types for the directory and file in question: # matchpathcon /var/run/NetworkManager /var/run/NetworkManager/resolv.conf /var/run/NetworkManager system_u:object_r:NetworkManager_var_run_t:s0 /var/run/NetworkManager/resolv.conf system_u:object_r:net_conf_t:s0
(In reply to Zdenek Pytela from comment #6) > Sumit, > > Definitely there is no problem with allowing it. > > Eike, > > The general approach is to allow a rule only when it is required. In this > case though we are solving an access of sssd to NetworkManager runtime > directory. > To your second question: before accessing a file, all directories in the > filesystem hierarchy need to be searched first. Then it is a matter of > implementation in the software if the directory is only searched to get > access to the file or its whole content is read or even map-read, maybe > Sumit/Michal can comment on that. Hi, in case /etc/resolv.conf is a symlink and the target does not exists SSSD checks if the target directory exists with the stat() call and starts monitoring the target directory with inotify. HTH bye, Sumit > > The selinux-policy denied just sssd the access to the NetworkManager runtime > directory, the permission to read the resolv.conf file is allowed. See the > types for the directory and file in question: > > # matchpathcon /var/run/NetworkManager /var/run/NetworkManager/resolv.conf > /var/run/NetworkManager system_u:object_r:NetworkManager_var_run_t:s0 > /var/run/NetworkManager/resolv.conf system_u:object_r:net_conf_t:s0
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy-contrib/pull/214
commit b92b147d56125b4ca9124c00fe803c7bec83a5a7 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Zdenek Pytela <zpytela> Date: Wed Mar 4 17:34:52 2020 +0100 Mark nm-cloud-setup systemd units as NetworkManager_unit_file_t Mark /usr/lib/systemd/system/nm-cloud-setup\.(service|timer) as NetworkManager_unit_file_t to support automated adding a secondary ip to interfaces required in cloud environments. Backported to F31.
Please ignore comment#9, it's not related to this BZ. This commit msg is right one: commit 6ac41c5b089731d9c5509db5ef6eae5944263b20 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Zdenek Pytela <zpytela> Date: Fri Mar 6 16:29:15 2020 +0100 Allow sssd read NetworkManager's runtime directory Resolves: rhbz#1810404
FEDORA-2020-5afc749ee7 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5afc749ee7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5afc749ee7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5afc749ee7 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
*** Bug 1823684 has been marked as a duplicate of this bug. ***
I am not sure if bug: 1823684 can be considered as a duplicate since it is on F32, but I guess it is t he exact same root cause.
Similar problem has been detected: The directory in question is /run/NetworkManager. hashmarkername: setroubleshoot kernel: 5.6.2-301.fc32.x86_64 package: selinux-policy-3.14.5-32.fc32.noarch reason: SELinux is preventing sssd from 'read' accesses on the directory NetworkManager. type: libreport
David, It looks one permission is still missing, will be fixed in the package update.