Bug 1810404

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.