Bug 1958210 - selinux-policy is blocking alsa-state.service from executing modprobe and from writing to sysfs
Summary: selinux-policy is blocking alsa-state.service from executing modprobe and fro...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 35
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2031176 2033307 2035975 2049728 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-05-07 13:00 UTC by Hans de Goede
Modified: 2022-02-17 03:15 UTC (History)
13 users (show)

Fixed In Version: selinux-policy-35.15-1.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-17 03:15:04 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1974051 1 None None None 2022-02-10 10:49:56 UTC

Internal Links: 2049730 2049732

Description Hans de Goede 2021-05-07 13:00:33 UTC
Kernel 5.13 will have support to bind certain alsa mixer controls to LED triggers from userspace (to control the mute-LEDS found on some devices (typically embedded inside the keyboard's mute keys).

The idea behind this is that this way this, often device specific, policy info can be stored in userspace in ALSA UCM profile config files, in the same way how many device specific mixer configurations are also stored in userspace in UCM profiles.

I've been working on adding support for the mute LEDs on some devices using this new kernel capability, this involves adding a config snippet like this to the UCM profile for the device:

FixedBootSequence [
       exec "/sbin/modprobe snd_ctl_led"
       sysw "-/class/sound/ctl-led/speaker/card${CardNumber}/attach:DAC1 Playback Switch"
       sysw "-/class/sound/ctl-led/mic/card${CardNumber}/attach:ADC Capture Switch"
]

As you can see this does 2 things, it calls modprobe to load the kernel module implementing the new functionality and then it does 2 writes to files under sysfs.

In order for this to work properly I had to put selinux in permissive mode. While running in permissive mode the following AVCs related to this were generated:

type=AVC msg=audit(1620391593.920:122): avc:  denied  { execute } for  pid=549 comm="sh" name="kmod" dev="mmcblk1p4" ino=536329 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.920:123): avc:  denied  { read open } for  pid=549 comm="sh" path="/usr/bin/kmod" dev="mmcblk1p4" ino=536329 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.920:124): avc:  denied  { execute_no_trans } for  pid=549 comm="sh" path="/usr/bin/kmod" dev="mmcblk1p4" ino=536329 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.936:125): avc:  denied  { map } for  pid=549 comm="modprobe" path="/usr/bin/kmod" dev="mmcblk1p4" ino=536329 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:kmod_exec_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.957:126): avc:  denied  { read } for  pid=549 comm="modprobe" name="modprobe.d" dev="mmcblk1p4" ino=1175142 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=dir permissive=1
type=AVC msg=audit(1620391593.957:127): avc:  denied  { getattr } for  pid=549 comm="modprobe" path="/etc/modprobe.d/mlx4.conf" dev="mmcblk1p4" ino=1176808 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.968:128): avc:  denied  { read } for  pid=549 comm="modprobe" name="kvm.conf" dev="mmcblk1p4" ino=1176803 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.968:129): avc:  denied  { open } for  pid=549 comm="modprobe" path="/etc/modprobe.d/kvm.conf" dev="mmcblk1p4" ino=1176803 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:modules_conf_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.969:130): avc:  denied  { read } for  pid=549 comm="modprobe" name="modules.softdep" dev="mmcblk1p4" ino=539755 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.969:131): avc:  denied  { open } for  pid=549 comm="modprobe" path="/usr/lib/modules/5.12.0+/modules.softdep" dev="mmcblk1p4" ino=539755 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.969:132): avc:  denied  { getattr } for  pid=549 comm="modprobe" path="/usr/lib/modules/5.12.0+/modules.softdep" dev="mmcblk1p4" ino=539755 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.969:133): avc:  denied  { map } for  pid=549 comm="modprobe" path="/usr/lib/modules/5.12.0+/modules.dep.bin" dev="mmcblk1p4" ino=539760 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=file permissive=1
type=AVC msg=audit(1620391593.985:134): avc:  denied  { module_load } for  pid=549 comm="modprobe" scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:system_r:alsa_t:s0 tclass=system permissive=1
type=AVC msg=audit(1620391594.022:135): avc:  denied  { write } for  pid=541 comm="alsactl" name="attach" dev="sysfs" ino=32883 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=1

It seems to me that this can be simplified into 2 problems (but I'm not a selinux expert):

1. The selinux policy for the alsa-state.service needs to be amended to allow executing modprobe; and allowing a transition to kmod_t on this execute which should fix all but one of the AVCs above

2. The selinux policy for the alsa-state.service needs to be amended to allow it to write to sysfs files.

If you can provide me with a selinux-module source for me to add with "semodule -i" to test, then I would be more then happy to test any suggested changes to make sure that they actually fix this.

Comment 1 Zdenek Pytela 2021-05-07 16:36:26 UTC
Hans,

Thank you for the detailed description. I think you are also correct with the solution.

# cat local_alsa_state.cil
(allow alsa_t kmod_exec_t (file (getattr open map read execute ioctl execute_no_trans)))
(allow alsa_t kmod_t (process (transition)))
(typetransition alsa_t kmod_exec_t process kmod_t)
(allow kmod_t alsa_t (fd (use)))
(allow kmod_t alsa_t (fifo_file (getattr read write append ioctl lock)))
(allow kmod_t alsa_t (process (sigchld)))
(allow alsa_t sysfs_t (file (getattr write)))
# semodule -i local_alsa_state.cil

Regarding sysfs: There is only need to write to existing files? The file descriptor is inherited so that just write permission is needed?
Once implemented, will there be a way to test the feature?
Will this kernel also get to F34 later?

If there are further denials, it would be helpful to enable full auditing:

1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run the scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 2 Ondrej Mosnacek 2021-05-07 16:50:46 UTC
(In reply to Zdenek Pytela from comment #1)
> Regarding sysfs: There is only need to write to existing files?

Sysfs files are usually created by the kernel, so that wouldn't be surprising.

> The file descriptor is inherited so that just write permission is needed?

$ sesearch -s alsa_t -t sysfs_t -A
allow alsa_t sysfs_t:dir { ioctl lock read };
allow alsa_t sysfs_t:file { getattr ioctl lock open read };
allow alsa_t sysfs_t:lnk_file { getattr read };
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow domain sysfs_t:dir { getattr open search };
allow domain sysfs_t:filesystem getattr;

So I think it needs also open/read/getattr, but these are already granted today.

> Will this kernel also get to F34 later?

I'd say it's very likely. F33 started with 5.8.x and now it's at 5.11.x. F34 is starting at 5.11.x, so it'll probably get up to 5.14 or 5.15 before going EOL.

Comment 3 Ben Cotton 2021-08-10 13:46:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 4 Zdenek Pytela 2022-02-08 18:34:56 UTC
*** Bug 2031176 has been marked as a duplicate of this bug. ***

Comment 5 Zdenek Pytela 2022-02-08 18:35:05 UTC
*** Bug 2033307 has been marked as a duplicate of this bug. ***

Comment 6 Zdenek Pytela 2022-02-08 18:35:15 UTC
*** Bug 2035975 has been marked as a duplicate of this bug. ***

Comment 7 Zdenek Pytela 2022-02-08 18:35:41 UTC
*** Bug 2049728 has been marked as a duplicate of this bug. ***

Comment 8 Jaroslav Kysela 2022-02-08 18:59:12 UTC
Note that new AMD laptops (standard hw) with the digital microphones are using this UCM scheme for the Microphone LED control. This issue should have higher priority - I have already bug reports that the microphone LEDs are not working on those machines.

Comment 9 Hans de Goede 2022-02-09 11:06:28 UTC
(In reply to Jaroslav Kysela from comment #8)
> Note that new AMD laptops (standard hw) with the digital microphones are
> using this UCM scheme for the Microphone LED control. This issue should have
> higher priority - I have already bug reports that the microphone LEDs are
> not working on those machines.

Note there is a solution suggested in comment 1, I just never got around to testing this. If you have hw + time to test this then that would be great.

Comment 10 bjoern.daase 2022-02-09 12:41:33 UTC
Hans, I have affected hardware. If you can create a scratch build of the necessary components as well as instructions on how to test, I'm happy to help.

Comment 11 Hans de Goede 2022-02-09 12:45:47 UTC
Bjoern, thank you for your offer to help.

There is not yet an updated package / selinux polciy for this, instead the request from comment 1 is to test by adding a local selinux config module, to do this create a file named "local_alsa_state.cil" with the following contents:

(allow alsa_t kmod_exec_t (file (getattr open map read execute ioctl execute_no_trans)))
(allow alsa_t kmod_t (process (transition)))
(typetransition alsa_t kmod_exec_t process kmod_t)
(allow kmod_t alsa_t (fd (use)))
(allow kmod_t alsa_t (fifo_file (getattr read write append ioctl lock)))
(allow kmod_t alsa_t (process (sigchld)))
(allow alsa_t sysfs_t (file (getattr write)))

And then as root run:

semodule -i local_alsa_state.cil

After this things will hopefully work with selinux in enforcing mode. If things still do not work after this, see comment 1 on how to gather the necessary info to help debug this further.

Comment 12 bjoern.daase 2022-02-09 12:55:52 UTC
Thanks a lot, Hans.

I have put selinux back into enforcing mode, created and added the selinux config module, and rebooted.
After I rebooted, the MIC LED was in the correct state and I was able to toggle it using the FN keys as expected :)

Comment 13 Jaroslav Kysela 2022-02-09 13:02:18 UTC
I confirm that things works with the above rules. The alsa library (alsa-lib) also uses the setpgid call for the child tasks. The result is ignored, but it may be worth to add this to selinux rules, too.

  type=AVC msg=audit(9.2.2022 13:59:04.521:206) : avc:  denied  { setpgid } for  pid=926 comm=alsactl scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:system_r:alsa_t:s0 tclass=process permissive=0

Comment 14 Hans de Goede 2022-02-09 13:05:06 UTC
Zdenek, sorry for completely dropping the ball on following up on comment 1.

Bjoern and Jaroslav have just tested the suggested selinux policy module from comment 1 and confirmed that this fixes things (thank you Bjoern and Jaroslav).

Zdenek, can you add the now tested selinux rules from comment 1 to the targeted policy to resolve this bug please?

Note that as Jaroslav mentions in comment 13 there still is a single AVC being logged, since we don't want any AVCs getting logged that still needs to be fixed on top of the rules from comment 1.

Comment 15 Zdenek Pytela 2022-02-09 20:12:37 UTC
Hi all,

Thank you for testing and your contributions. There are still a few problems to clarify

I wondered if just allowing alsa execute kmod would be a better solution, but probably not. Regarding this one:

(In reply to Jaroslav Kysela from comment #13)
> I confirm that things works with the above rules. The alsa library
> (alsa-lib) also uses the setpgid call for the child tasks. The result is
> ignored, but it may be worth to add this to selinux rules, too.
If the result is ignored, why allow it then? Do you know what is this syscall used for?
A problem is that we can have this request dontaudited, which would result in no denial, but it makes things harder in the future to troubleshoot if the same syscall was actually used.

Comment 16 Zdenek Pytela 2022-02-10 10:49:57 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/1060

I don't think I need any further answer, feel free to review the commit and/or try

Checks -> Artifacts -> rpms

from the PR.

Comment 17 Zdenek Pytela 2022-02-10 11:44:11 UTC
Jaroslave,

also note this denial is not addressed:

type=AVC msg=audit(1.2.2022 14:08:47.027:152) : avc:  denied  { execute } for  pid=933 comm=alsactl name=test.sh dev="nvme0n1p4" ino=2500949 scontext=system_u:system_r:alsa_t:s0 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file permissive=0 

Looks like a test script execution.

Comment 18 Zdenek Pytela 2022-02-11 10:47:28 UTC
Merged and F35 backport initiated:
https://github.com/fedora-selinux/selinux-policy/pull/1063

Comment 19 Fedora Update System 2022-02-15 14:58:06 UTC
FEDORA-2022-aa5df3a7eb has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

Comment 20 Fedora Update System 2022-02-16 01:50:50 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-aa5df3a7eb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

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

Comment 21 Fedora Update System 2022-02-17 03:15:04 UTC
FEDORA-2022-aa5df3a7eb has been pushed to the Fedora 35 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.