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

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

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

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

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

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

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

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.

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

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.

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.

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 :)

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

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.

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.

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.

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.

Merged and F35 backport initiated:
https://github.com/fedora-selinux/selinux-policy/pull/1063

FEDORA-2022-aa5df3a7eb has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-aa5df3a7eb

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.

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.