Bug 2153882 - SELinux blocks systemd-integrityservice.service from loading dm-integrity module
Summary: SELinux blocks systemd-integrityservice.service from loading dm-integrity module
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-12-15 18:11 UTC by Chris Adams
Modified: 2025-04-25 11:36 UTC (History)
15 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)
debug log of a boot where integrity service failed (3.32 MB, text/plain)
2022-12-16 18:16 UTC, Chris Adams
no flags Details

Description Chris Adams 2022-12-15 18:11:38 UTC
I created an integrity device using integritysetup, and put the info in /etc/integritytab. A systemd-integritysetup@<name>.service was auto-generated, but failed on boot (and on restart attempts after boot). The issue is that the dm_integrity module wasn't loaded, either automatically or by a service.

I put "dm-integrity" in /etc/modules-load.d/integrity.conf, and the device is opened on boot (as expected).

I think the module should be loaded by the integritysetup service.

Comment 1 Yu Watanabe 2022-12-15 19:13:35 UTC
Fix is waiting in https://github.com/systemd/systemd/pull/25764
If possible, please test the PR.
Thank you.

Comment 2 Chris Adams 2022-12-15 21:22:56 UTC
I tried that on top of systemd-251.9-587 (from Fedora 37 updates-testing), but it didn't work. Wouldn't it also need to add a Requires=modprobe?

Comment 3 Yu Watanabe 2022-12-16 06:48:31 UTC
Yeah, I forgot that. Now, it has `Wants=`, instead of `Requires=`. Could you try again?

BTW, Lennart asks why the module is not loaded automatically. Could you show the relevant journal logs? Maybe, booting with systemd.log_level=debug kernel command line option provides much relevant logs.

Comment 4 Zbigniew Jędrzejewski-Szmek 2022-12-16 06:48:52 UTC
https://github.com/systemd/systemd/pull/25764/

Comment 5 Chris Adams 2022-12-16 18:16:33 UTC
Created attachment 1933139 [details]
debug log of a boot where integrity service failed

I'm not sure why the systemd path isn't getting the module loaded. If I just run "integritysetup open --allow-discards /dev/vdb storage" after boot, it works (the dm-integrity module is loaded automatically). If I close the device and unload the module, "systemctl restart systemd-integritysetup" still fails. However the systemd service works is somehow not the same?

I'm attaching a log with debug enabled.

Comment 6 Chris Adams 2022-12-16 18:20:44 UTC
Hmm... "/usr/lib/systemd/systemd-integritysetup attach storage /dev/vdb - allow-discards" (without the module pre-loaded) also works (module auto-loaded and device opened).

Comment 7 Chris Adams 2022-12-16 20:51:39 UTC
It's an SELinux thing I guess? When set permissive mode AND disable dontaudit, I see this denial when I try to start the service:

type=AVC msg=audit(1671223759.214:266): avc:  denied  { module_request } for  pid=1127 comm="systemd-integri" kmod="dm-integrity" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system permissive=1

I'm not sure if that's a case of systemd should do something different or SELinux should allow this - if it's SELinux, feel free to reassign over to selinux-policy.

Comment 8 Zbigniew Jędrzejewski-Szmek 2022-12-20 12:56:38 UTC
The systemd upstream PR was "rejected" (the cleanup part was merged, but the patch that would work around the selinux denial was dropped). I'm unsetting "POST".

Yeah, this should be fixed in the selinux policy.

Comment 9 Chris Adams 2023-02-21 20:23:41 UTC
Is there anything else needed to get the SELinux policy to allow systemd-integritysetup to get the dm-integrity module loaded? It's kind of useless otherwise.

Comment 10 Aoife Moloney 2023-11-23 00:46:38 UTC
This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 11 Chris Adams 2023-11-23 15:44:37 UTC
Still a problem in rawhide. Can we get the SELinux policy updated to allow systemd-integritysetup.service to work?

Comment 12 Zdenek Pytela 2023-11-23 16:08:45 UTC
(In reply to Chris Adams from comment #11)
> Still a problem in rawhide. Can we get the SELinux policy updated to allow
> systemd-integritysetup.service to work?

It requires confining the service. Do you have any use case which could be used for testing?

Comment 13 Chris Adams 2023-11-23 17:12:16 UTC
To test, you need an unused block device. In a VM, I just attach an additional drive, making it /dev/vdb in the VM. Then you install the tool, create an integrity device, put it in the integritytab, and reboot.

dnf install integritysetup
integritysetup format /dev/vdb
echo itst /dev/vdb - - >> /etc/integritytab

On boot, systemctl will show the systemd-integrityservice failed. Configure SELINUX=permissive and reboot and it works.

Comment 14 Aoife Moloney 2024-02-15 22:55:47 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle.
Changing version to 40.

Comment 15 Aoife Moloney 2025-04-25 10:04:22 UTC
This message is a reminder that Fedora Linux 40 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '40'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 40 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.


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