Bug 2111632

(In reply to epassaro from comment #0)
> Description of problem:
> 
> In CoreOS 4.11, NetworkManager dispatcher script resolve-prepender has
> selinux context NetworkManager_initrc_exec_t instead of
> NetworkManager_exec_t and is not allowed to run hostnamectl successfully 
Which package is this script a part of?

> IIUC, with NetworkManager_exec_t instead, it would be mapped to the 
> NetworkManager_t domain which would be allowed to run hostnamectl via
> systemd_dbus_chat_hostnamed rule.
> 
> hostnamectl fails with timeout, and this affects OCP 4.11 cluster
> installation with Infrastructure Operator (see bug
> https://bugzilla.redhat.com/show_bug.cgi?id=2103744, and discussion on its
> parent bug https://bugzilla.redhat.com/show_bug.cgi?id=2105069#c7) 
Can you show the AVC denials? Supposedly it is dbus-related because of:

rhel87# sesearch -A -s initrc_t -t systemd_hostnamed_t -c dbus
allow dbusd_unconfined nsswitch_domain:dbus send_msg;
allow dbusd_unconfined systemd_hostnamed_t:dbus send_msg;
rhel87# sesearch -A -s systemd_hostnamed_t -t initrc_t -c dbus
<>

> Is this a regression in the selinux policy or this has always been working
> like this?
I am not aware of any change in selinux-policy which would have this effect.

sudo cat /var/log/audit/audit.log | grep AVC
type=USER_AVC msg=audit(1659032710.225:59): pid=1684 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.23 spid=2281 tpid=2280 scontext=system_u:system_r:systemd_hostnamed_t:s0 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus permissive=0  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'UID="dbus" AUID="unset" SAUID="dbus"

Thanks. Given the RHEL 8.7 state of development, we will consider it for RHEL 8.8 if you are fine with it.

(In reply to Zdenek Pytela from comment #1)
> (In reply to epassaro from comment #0)
> > Description of problem:
> > 
> > In CoreOS 4.11, NetworkManager dispatcher script resolve-prepender has
> > selinux context NetworkManager_initrc_exec_t instead of
> > NetworkManager_exec_t and is not allowed to run hostnamectl successfully 
> Which package is this script a part of?

This is specific to OpenShift. Are downstream users supposed to deploy their own specific selinux policies for their specific NetworkManager dispatcher scripts? Why would NM dispatcher scripts not be allowed to do the same stuff NM is allowed to do?

(In reply to Jaime Caamaño Ruiz from comment #4)
> This is specific to OpenShift. Are downstream users supposed to deploy their
> own specific selinux policies for their specific NetworkManager dispatcher
> scripts? Why would NM dispatcher scripts not be allowed to do the same stuff
> NM is allowed to do?

If I understand the words of Thomas Haller (one of the NetworkManager developers),
SELinux should differentiate between NetworkManager and NM dispatcher scripts:

 * https://bugzilla.redhat.com/show_bug.cgi?id=1989070#c0

(In reply to Zdenek Pytela from comment #3)
> Thanks. Given the RHEL 8.7 state of development, we will consider it for
> RHEL 8.8 if you are fine with it.

So if I understand correctly, we are waiting for this change

https://github.com/fedora-selinux/selinux-policy/commit/50ed356c5d7c3daa7ef72351b06beb58ed499371

Which will make user dispatcher scripts run unconfined? Or is it something else altogether?

(In reply to Milos Malik from comment #5)
> (In reply to Jaime Caamaño Ruiz from comment #4)
> > This is specific to OpenShift. Are downstream users supposed to deploy their
> > own specific selinux policies for their specific NetworkManager dispatcher
> > scripts? Why would NM dispatcher scripts not be allowed to do the same stuff
> > NM is allowed to do?
> 
> If I understand the words of Thomas Haller (one of the NetworkManager
> developers),
> SELinux should differentiate between NetworkManager and NM dispatcher
> scripts:
> 
>  * https://bugzilla.redhat.com/show_bug.cgi?id=1989070#c0

I see. Trying to find out what does that mean for downstream users.

(In reply to Jaime Caamaño Ruiz from comment #4)
> > > In CoreOS 4.11, NetworkManager dispatcher script resolve-prepender has
> > > selinux context NetworkManager_initrc_exec_t instead of
> > > NetworkManager_exec_t and is not allowed to run hostnamectl successfully 
> > Which package is this script a part of?
> 
> This is specific to OpenShift. Are downstream users supposed to deploy their
> own specific selinux policies for their specific NetworkManager dispatcher
> scripts? Why would NM dispatcher scripts not be allowed to do the same stuff
> NM is allowed to do?
nm and nm-dispatcher have different context, actually nm-dispatcher runs in an unconfined domain in RHEL 8 so is allowed a superset of rules. In this case, it is a communication from other domain which is not allowed.
  # sesearch -A -s systemd_hostnamed_t -t initrc_t -c dbus -p send_msg
<>

Deploying a particular plugin specific rules is a good idea, but, based on experience in Fedora, is a long process.

(In reply to Milos Malik from comment #5)
> If I understand the words of Thomas Haller (one of the NetworkManager
> developers),
> SELinux should differentiate between NetworkManager and NM dispatcher
> scripts:
> 
>  * https://bugzilla.redhat.com/show_bug.cgi?id=1989070#c0
Correct. Based on this statement, we started to confine individual plugins; after 8 months we still can see the process as incomplete.

(In reply to Jaime Caamaño Ruiz from comment #6)
> (In reply to Zdenek Pytela from comment #3)
> > Thanks. Given the RHEL 8.7 state of development, we will consider it for
> > RHEL 8.8 if you are fine with it.
> 
> So if I understand correctly, we are waiting for this change
> 
> https://github.com/fedora-selinux/selinux-policy/commit/
> 50ed356c5d7c3daa7ef72351b06beb58ed499371
No. Implementation in RHEL 8 will not change.

> Which will make user dispatcher scripts run unconfined? Or is it something
> else altogether?
The scripts already run in an unconfined domain.

> I see. Trying to find out what does that mean for downstream users.
Nothing in RHEL 8.

Can we have that as part of 8.7?
I'm sure Chad can help reproduce if needed.

For the correct fix and successful bug verification, we need the reproducer. Once we have it, we can retarget the bz to 8.7, but it needs to happen in a week time.
We also need someone from your team test the service functionality after the change.

Hi Zdenek Pytela - We are working on reproducing and will let you know the details once we have it.

I've submitted a Fedora draft PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/1334

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-2023:2965