2111632 – NM dispatcher scripts cannot use hostnamectl and dbus chat with hostnamed

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2111632 - NM dispatcher scripts cannot use hostnamectl and dbus chat with hostnamed

Summary: NM dispatcher scripts cannot use hostnamectl and dbus chat with hostnamed

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	8.6
Hardware:	Unspecified
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	8.8
Assignee:	Zdenek Pytela
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	2111526
TreeView+	depends on / blocked

Reported:	2022-07-27 17:13 UTC by epassaro
Modified:	2023-05-16 11:01 UTC (History)
CC List:	8 users (show)
Fixed In Version:	selinux-policy-3.14.3-111.el8
Doc Type:	No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed:	2023-05-16 09:03:44 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Priority	Status	Summary	Last Updated
Github	fedora-selinux selinux-policy pull 1460	None	open	Allow systemd-hostnamed dbus chat with init scripts	2022-11-11 11:48:47 UTC
Red Hat Issue Tracker	RHELPLAN-129321	None	None	None	2022-07-27 17:18:12 UTC
Red Hat Product Errata	RHBA-2023:2965	None	None	None	2023-05-16 09:04:03 UTC

Description epassaro 2022-07-27 17:13:08 UTC

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 

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) 

Is this a regression in the selinux policy or this has always been working like this?

How reproducible:
100% reproducible

Comment 1 Zdenek Pytela 2022-07-29 10:50:16 UTC

(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.

Comment 2 epassaro 2022-07-29 10:58:03 UTC

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"

Comment 3 Zdenek Pytela 2022-07-29 11:06:25 UTC

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

Comment 4 Jaime Caamaño Ruiz 2022-08-01 14:08:42 UTC

(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?

Comment 5 Milos Malik 2022-08-01 14:48:29 UTC

(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

Comment 6 Jaime Caamaño Ruiz 2022-08-01 18:02:11 UTC

(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.

Comment 7 Zdenek Pytela 2022-08-02 08:49:04 UTC

(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.

Comment 8 Oved Ourfali 2022-08-10 04:50:33 UTC

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

Comment 9 Zdenek Pytela 2022-08-10 07:52:01 UTC

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.

Comment 10 Chad Crum 2022-08-10 16:39:47 UTC

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

Comment 13 Zdenek Pytela 2022-08-11 15:26:58 UTC

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

Comment 26 errata-xmlrpc 2023-05-16 09:03:44 UTC

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

Note You need to log in before you can comment on or make changes to this bug.