Bug 2027994

Summary:	/dev/ng0n1 has device_t
Product:	Red Hat Enterprise Linux 9	Reporter:	Jan Pazdziora (Red Hat) <jpazdziora>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED ERRATA	QA Contact:	Milos Malik <mmalik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	9.0	CC:	jpazdziora, lvrabec, mmalik, omosnace, ssekidde
Target Milestone:	rc	Keywords:	AutoVerified, Triaged
Target Release:	9.0
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:	selinux-policy-34.1.20-1.el9	Doc Type:	No Doc Update
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-05-17 15:49:53 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jan Pazdziora (Red Hat) 2021-12-01 08:37:30 UTC

Description of problem:

On one ARM machine, we've observed /dev/ng0n1 with device_t label.

Version-Release number of selected component (if applicable):

selinux-policy-34.1.18-1.el9.noarch

How reproducible:

Deterministic.

Steps to Reproduce:
1. ls -laZ /dev/ng0n1 | grep device_t

Actual results:

crw-------. 1 root root system_u:object_r:device_t:s0 241, 0 Dec  1 03:29 /dev/ng0n1

Expected results:

No line returned.

Additional info:

Comment 2 Zdenek Pytela 2021-12-06 13:41:27 UTC

Ondrej,

Is fixed_disk_device_t the proper type for devices like /dev/ng0n1?

I found some references in drivers/nvme/host.

I assume the name regexp always matches "ng%dn%d" and always is a char device.

Comment 3 Ondrej Mosnacek 2021-12-06 14:25:39 UTC

(In reply to Zdenek Pytela from comment #2)
> Is fixed_disk_device_t the proper type for devices like /dev/ng0n1?

It is a control device for low-level operations on an NVME device, so I'd be reluctant to label it as "fixed disk device". But unfortunately we already overload it in the current policy, so I guess that ship has sailed by now :/ Ideally we would give the control char devices a separate label (e.g. nvme_control_device_t for /dev/ng%dn%d, /dev/nvme%d (not /dev/nvme%dn%d(p%d)? - these are actual "fixed disk" block devices), and /dev/nvme-subsys%d), but it could end up being a deep rabbit hole...

Given all of the above, I'd say labeling it fixed_disk_device_t as we already do for /dev/nvme%d will be best for now.

> I assume the name regexp always matches "ng%dn%d" and always is a char
> device.

Yes, that's correct. We could also proactively add /dev/nvme-subsys%d, which also appears in NVME code (should also be a char device).

Comment 4 Zdenek Pytela 2021-12-15 12:19:07 UTC

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

Please note only existing type was added for the devices, no additional access allowed to domains.

Comment 15 errata-xmlrpc 2022-05-17 15:49:53 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 (new packages: selinux-policy), 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:3918