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