Bug 1990463 - SELinux is preventing smartd from getattr access on the chr_file /dev/nvme1.
Summary: SELinux is preventing smartd from getattr access on the chr_file /dev/nvme1.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: smartmontools
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michal Hlavinka
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1993589 1994950 1996243 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-08-05 13:08 UTC by Garry T. Williams
Modified: 2021-08-25 20:04 UTC (History)
14 users (show)

Fixed In Version: smartmontools-7.2-10.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-25 20:04:34 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Garry T. Williams 2021-08-05 13:08:19 UTC
Description of problem:
SELinux is preventing smartd from getattr access on the chr_file /dev/nvme1.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-3.14.6-39.fc33.noarch
smartmontools-selinux-7.2-7.fc33.noarch

How reproducible: uncertain


Steps to Reproduce: uncertain


Additional info:
Source Context                system_u:system_r:fsdaemon_t:s0
Target Context                system_u:object_r:nvme_device_t:s0
Target Objects                /dev/nvme1 [ chr_file ]
Source                        smartd
Source Path                   smartd
Port                          <Unknown>
Host                          gtw
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.6-39.fc33.noarch
Local Policy RPM              smartmontools-selinux-7.2-7.fc33.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     gtw
Platform                      Linux gtw 5.13.7-100.fc33.x86_64 #1 SMP Sat Jul 31
                              14:19:28 UTC 2021 x86_64 x86_64
Alert Count                   4
First Seen                    2021-08-05 08:44:31 EDT
Last Seen                     2021-08-05 08:44:32 EDT
Local ID                      450b78c9-58d5-42e6-84be-70b00af387ae

Comment 1 James Ralston 2021-08-10 18:25:54 UTC
What appears to have happened here is that SELinux policy specific to smartmontools was forked from selinux-policy-targeted (source RPM = selinux-policy) to smartmontools-selinux (source RPM = smartmontools).

In that process, it would appear that certain regressions slipped in, one of which removed the ability for smartd to access NVMe drives.

More specifically: smartd runs in the fsdaemon_t context, which SELinux now blocks from accessing NVMe devices:

$ restorecon -FR -v /dev

$ ls -lsaZ /dev/nvme*
0 crw-------. 1 root root system_u:object_r:nvme_device_t:s0 239, 0 Aug  9 03:38 /dev/nvme0
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 0 Aug  9 03:38 /dev/nvme0n1
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 1 Aug  9 03:38 /dev/nvme0n1p1
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 2 Aug  9 03:38 /dev/nvme0n1p2
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 3 Aug  9 03:38 /dev/nvme0n1p3
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 4 Aug  9 03:38 /dev/nvme0n1p4
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 5 Aug  9 03:38 /dev/nvme0n1p5
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 6 Aug  9 03:38 /dev/nvme0n1p6
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 7 Aug  9 03:38 /dev/nvme0n1p7
0 brw-rw----. 1 root disk system_u:object_r:nvme_device_t:s0 259, 8 Aug  9 03:38 /dev/nvme0n1p8

$ semanage permissive -a fsdaemon_t

$ systemctl try-restart smartd

$ ausearch -m avc -ts today | audit2allow

#============= fsdaemon_t ==============
allow fsdaemon_t nvme_device_t:chr_file { ioctl open read };

This is a regression/error. Processes that run in fsdaemon_t should be permitted to perform the above system calls on nvme_device_t character devices. This worked successfully before smartmontools-specific SELinux policy was forked from selinux-policy to smartmontools.

Comment 2 Ondrej Mosnacek 2021-08-10 18:36:12 UTC
It may be related that we changed the label of NVME devices to the more suitable fixed_disk_device_t in February (AFAIK only in F34+):
https://github.com/fedora-selinux/selinux-policy/commit/9613e80506e7ffa37e9b150f2a3f8641dd7c26ea

If the smartmontools policy was forked from the rawhide snapshot and then brought into F33, this may have caused it to miss the rules for the legacy nvme_device_t type.

Comment 3 James Ralston 2021-08-10 19:01:46 UTC
(In reply to Ondrej Mosnacek from comment #2)
> It may be related that we changed the label of NVME devices to the more
> suitable fixed_disk_device_t in February (AFAIK only in F34+):
> https://github.com/fedora-selinux/selinux-policy/commit/
> 9613e80506e7ffa37e9b150f2a3f8641dd7c26ea
> 
> If the smartmontools policy was forked from the rawhide snapshot and then
> brought into F33, this may have caused it to miss the rules for the legacy
> nvme_device_t type.

That seems likely, yes. On Fedora 33 the correct label is definitely nvme_device_t.

I am testing the following policy module:

module smartmon-bz1990463 1.0;

require {
        type fsdaemon_t;
        type nvme_device_t;
        class chr_file { getattr ioctl open read };
}

#============= fsdaemon_t ==============
allow fsdaemon_t nvme_device_t:chr_file { getattr ioctl open read };

Restarting smartd with this module in place throws no SELinux denials.

(Note that getattr is required in addition to (ioctl open read).)

Comment 4 Michal Hlavinka 2021-08-16 20:56:45 UTC
*** Bug 1993589 has been marked as a duplicate of this bug. ***

Comment 5 Michal Hlavinka 2021-08-16 21:19:59 UTC
Thanks for figuring out the missing part

Comment 6 Michal Hlavinka 2021-08-18 15:46:39 UTC
*** Bug 1994950 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Update System 2021-08-18 15:48:39 UTC
FEDORA-2021-29bd7c851f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

Comment 8 Matthias Andree 2021-08-18 16:36:27 UTC
(In reply to Fedora Update System from comment #7)
> FEDORA-2021-29bd7c851f has been submitted as an update to Fedora 33.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

no joy for me with a slightly different but related bug (I reloaded unit files and this is what happens on systemctl restart smartd) - did I miss any other steps after upgrading the smartmontools and smartmontools-selinux RPMs?

Source Context                system_u:system_r:fsdaemon_t:s0
Target Context                system_u:object_r:nvme_device_t:s0
Target Objects                /dev/nvme0 [ chr_file ]
Source                        smartd
Source Path                   smartd
Port                          <Unbekannt>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.6-39.fc33.noarch
Local Policy RPM              smartmontools-selinux-7.2-9.fc33.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.13.9-100.fc33.x86_64 #1 SMP Mon
                              Aug 9 12:04:50 UTC 2021 x86_64 x86_64
Alert Count                   4
First Seen                    2021-08-18 18:21:40 CEST
Last Seen                     2021-08-18 18:26:08 CEST
Local ID                      017c8780-b33a-44e1-a91a-f3796dff268f

Raw Audit Messages
type=AVC msg=audit(1629303968.637:115092): avc:  denied  { open } for  pid=456634 comm="smartd" path="/dev/nvme0" dev="devtmpfs" ino=328 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:nvme_device_t:s0 tclass=chr_file permissive=0


Hash: smartd,fsdaemon_t,nvme_device_t,chr_file,open

Comment 9 Garry T. Williams 2021-08-18 16:52:22 UTC
(In reply to Ondrej Mosnacek from comment #2)
> It may be related that we changed the label of NVME devices to the more
> suitable fixed_disk_device_t in February (AFAIK only in F34+):
> https://github.com/fedora-selinux/selinux-policy/commit/
> 9613e80506e7ffa37e9b150f2a3f8641dd7c26ea

To confirm, the error goes away after sudo chcon -t fixed_disk_device_t /dev/nvme* but not after sudo /sbin/restorecon -v /dev/nvme* .

I tested with the just built smartmontools-1:7.2-9.fc33.x86_64.

Comment 10 Fedora Update System 2021-08-19 01:52:05 UTC
FEDORA-2021-29bd7c851f has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-29bd7c851f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Zdenek Pytela 2021-08-23 12:03:26 UTC
(In reply to Ondrej Mosnacek from comment #2)
> It may be related that we changed the label of NVME devices to the more
> suitable fixed_disk_device_t in February (AFAIK only in F34+):
> https://github.com/fedora-selinux/selinux-policy/commit/
> 9613e80506e7ffa37e9b150f2a3f8641dd7c26ea
Correct, only F34+

f33# seinfo -xt nvme_device_t

Types: 1
   type nvme_device_t, device_node;

> 
> If the smartmontools policy was forked from the rawhide snapshot and then
> brought into F33, this may have caused it to miss the rules for the legacy
> nvme_device_t type.

Comment 12 Fedora Update System 2021-08-23 14:34:19 UTC
FEDORA-2021-29bd7c851f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

Comment 13 Fedora Update System 2021-08-24 02:08:08 UTC
FEDORA-2021-29bd7c851f has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-29bd7c851f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 14 Michal Hlavinka 2021-08-24 21:15:11 UTC
*** Bug 1996243 has been marked as a duplicate of this bug. ***

Comment 15 Fedora Update System 2021-08-25 20:04:34 UTC
FEDORA-2021-29bd7c851f has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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