Bug 1990463

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.

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.

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

*** Bug 1993589 has been marked as a duplicate of this bug. ***

Thanks for figuring out the missing part

*** Bug 1994950 has been marked as a duplicate of this bug. ***

FEDORA-2021-29bd7c851f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

(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

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

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.

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

FEDORA-2021-29bd7c851f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-29bd7c851f

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.

*** Bug 1996243 has been marked as a duplicate of this bug. ***

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.