Bug 1986076

@zpytela I am a bit overwhelmed by providing a patch for this.

Could I get some guidance? Or useful howtos, or a similar example that I can follow/adjust?

Thomas,

Sorry for the delay, I'd like to assure you this bug did not go out of our radar.

We can do it in selinux-policy, create a new type, allow some basic permissions and continue. Later, it would help if there were some tests to verify the resulting policy and interactions with other services.

(In reply to Zdenek Pytela from comment #2)

sounds great. Thank you!!

Similar to bz#1989070, I suppose we can make efforts to add this feature to the policy and have it verified by ITM 15 so that it gets into compose around the middle of 8.6 development phase. If it fails for any reason, we will take it out.

Can we get access both to the updated package and tests checking the service? Either Fedora or RHEL 8 (ideally both).

(In reply to Zdenek Pytela from comment #4)
> If it fails for any reason, we will take it out.

My concern about doing the development on RHEL 8 is that if it fails, we won't have it neither in RHEL 8.6, nor in RHEL 9.0. Wouldn't it make sense to focus on RHEL 9 first where potentially more disruptive changes could be done, and the backport already working solution to RHEL 8?

(In reply to Jan Pazdziora from comment #5)
> (In reply to Zdenek Pytela from comment #4)
> > If it fails for any reason, we will take it out.
> 
> My concern about doing the development on RHEL 8 is that if it fails, we
> won't have it neither in RHEL 8.6, nor in RHEL 9.0. Wouldn't it make sense
> to focus on RHEL 9 first where potentially more disruptive changes could be
> done, and the backport already working solution to RHEL 8?

We actually put new things into Fedora first and then it can be backported to any RHEL release if no big adjustments are needed.

> Can we get access both to the updated package and tests checking the service? Either Fedora or RHEL 8 (ideally both).


nm-sudo will be present upstream in upcoming NetworkManager 1.34 version (not yet released, but soon to happen).

On rhel-8.6 and rhel-9.0.0 the current packages are already a snapshot from `main` branch, which contains nm-sudo.
Find them in brew.

There is also our copr repo: https://copr.fedorainfracloud.org/coprs/networkmanager/NetworkManager-main/


Basically, check the version of your NetworkManager package. If it's >= 1.33, you have it.
You also have a suitable NetworkManager version if (and only if) /usr/libexec/nm-sudo exists.


https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=NetworkManager
https://brewweb.engineering.redhat.com/brew/search?match=glob&type=package&terms=NetworkManager


See comment 1 for how to test it.

> See comment 1 for how to test it.

Comment 1 is about how to test manually -- which may not be exactly the same, as when NetworkManager.service tries to talk to nm-sudo.

A more thorough test which checks whether NM is capable means to:

  - ensure to use NetworkManager version >= 1.33.

  - systemctl edit NetworkManager.service
    # Take away CapabilityBoundingSet=CAP_DAC_OVERRIDE from NetworkManager and restart the service:

      [Service]
      CapabilityBoundingSet=~CAP_DAC_OVERRIDE

  - ensure you have "NetworkManager-ovs" and "openvswitch" installed.

  - enable `level=TRACE` logging (read https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/contrib/fedora/rpm/NetworkManager.conf#L27 )

  - systemctl start openvswitch.service
  - systemctl restart NetworkManager.service

Now search the journal for "ovsdb: connect:"

   <trace> [1634021761.7360] ovsdb: connect: start connecting socket /run/openvswitch/db.sock on idle
   ...
   <trace> [1634021761.9032] ovsdb: connect: opening /run/openvswitch/db.sock failed ("error connecting socket (Permission denied)"). Retry with nm-sudo
   ...
   <trace> [1634021761.9661] ovsdb: connect: failure to get FD from nm-sudo: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Remote peer disconnected

which shows the problem. The FD was requested by NM sudo, but blocked by SELinux.

With `setenforce 0` instead the last line will be:

   <trace> [1634021879.1650] ovsdb: connect: connected successfully with FD from nm-sudo

Patrik is working on the PR:
https://github.com/fedora-selinux/selinux-policy/pull/977

I suppose the component can be switched to selinux-policy.

Hi Thomas,

we have already finished new policy for nm-sudo, but I will have one question. When I tried reproduce scenario and implement needed rules to new policy I found AVC, where nm-sudo want bypass read, write, and execute permission checks on socket:


time->Tue Dec 21 10:50:38 2021
type=PROCTITLE msg=audit(1640101838.497:243): proctitle="/usr/libexec/nm-sudo"
type=PATH msg=audit(1640101838.497:243): item=0 name="/run/openvswitch/db.sock" inode=1122 dev=00:1a mode=0140750 ouid=992 ogid=990 rdev=00:00 obj=system_u:object_r:openvswitch_var_run_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
type=CWD msg=audit(1640101838.497:243): cwd="/"
type=SOCKADDR msg=audit(1640101838.497:243): saddr=01002F72756E2F6F70656E767377697463682F64622E736F636B00
type=SYSCALL msg=audit(1640101838.497:243): arch=c000003e syscall=42 success=yes exit=0 a0=7 a1=7ffe8e01ad60 a2=1b a3=0 items=1 ppid=1 pid=989 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-sudo" exe="/usr/libexec/nm-sudo" subj=system_u:system_r:NetworkManager_sudo_t:s0 key=(null)
type=AVC msg=audit(1640101838.497:243): avc:  denied  { dac_override } for  pid=989 comm="nm-sudo" capability=1  scontext=system_u:system_r:NetworkManager_sudo_t:s0 tcontext=system_u:system_r:NetworkManager_sudo_t:s0 tclass=capability permissive=1


Please, do you know reason why need nm-sudo use this capability on the /run/openvswitch/db.sock?

Thank you,
Patrik

> Please, do you know reason why need nm-sudo use this capability on the /run/openvswitch/db.sock?

Because the file is:

```
# ls -la /run/openvswitch/db.sock
srwxr-x---. 1 openvswitch hugetlbfs 0 Dec 23 20:41 /run/openvswitch/db.sock
```

(on my Fedora. On RHEL this might look slightly different).



NetworkManager wants to talk to the ovsdb daemon via that UNIX socket.
As NetworkManager runs as root (and not a member hugetlbfs), it had (and still has) DAC_OVERRIDE capability to open the socket.

We want to drop the extra capability from NetworkManager, which is where nm-sudo comes.
NetworkManager will now ask nm-sudo to pass the file descriptor.

Of course, nm-sduo also doesn't run as openvswitch:hugetlbfs user, so nm-sudo has a similar problem. But we don't mind giving a strictly defined set of extra capabilities to nm-sudo (while we mind doing that for NetworkManager).


The chosen solution is that NM will drop CAP_DAC_OVERRIDE, while nm-sudo will have DAC_OVERRIDE capability.
(yes, you could imagine other solutions, like nm-sudo joining the group hugetlbfs -- which requires a different capability). 



Does that answer the question?

(thank you for the progress!!)

btw, it seems nm-sudo service is about to be renamed: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1047
Sorry about that.
All what changes is the naming, please sync with @bgalvani.

Beniamino,

We were about to merge selinux-policy changes in Fedora 35+rawhide. We now change the tool name provided it is considered the final name, but otherwise I suppose there is no need to wait until your change gets in Fedora.

> Does that answer the question?

Yes, absolutely.


Thank you,
Patrik

(In reply to Zdenek Pytela from comment #13)
> Beniamino,
> 
> We were about to merge selinux-policy changes in Fedora 35+rawhide. We now
> change the tool name provided it is considered the final name, but otherwise
> I suppose there is no need to wait until your change gets in Fedora.

Hi,

yes, nm-priv-helper is the final name that we agreed upon, and it was merged to the main branch:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/d68ab6b8f02a8de68ce6bb1207cfba4e995fd756

The rename will affect Fedora rawhide from the next package update (1.35.4) which will happen today. It doesn't affect F35, which doesn't ship the helper service.

Switching the component. If you feel this bz needs to be resolved in NetworkManager, feel free to change it back.

PR:https://github.com/fedora-selinux/selinux-policy/pull/977

A new commit to backport:
commit d8c7fa0c9b9e5b741e50c95d81d3474f099bb137 (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date:   Mon Feb 7 18:08:53 2022 +0100

    Allow nm-privhelper setsched permission and send system logs

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1995