As reported on the gentoo-hardened mailinglist [1], it seems that even on non-hardened systems alsactl wants to read the urandom device: """ Aug 21 08:45:49 dell-studio kernel: [ 8.588561] type=1400 audit(1345538718.587:4): avc: denied { read } for pid=1450 comm="alsactl" name="urandom" dev="tmpfs" ino=3255 scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Aug 21 08:45:49 dell-studio kernel: [ 8.588576] type=1400 audit(1345538718.587:6): avc: denied { open } for pid=1450 comm="alsactl" name="urandom" dev="tmpfs" ino=3255 scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Aug 21 08:45:49 dell-studio kernel: [ 8.588579] type=1400 audit(1345538718.587:7): avc: denied { open } for pid=1452 comm="alsactl" name="urandom" dev="tmpfs" ino=3255 scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file """ However, in the source code of alsa-utils I see no reference to rand() or srand() and I'm currently too oblivious to what calls would require this access. It is not certain this is causing erroneous behavior as there are other alsa_t related denials. In the end though, no sound device is detected (or pulseaudio can't find it at least). Reproducible: Always
[1] http://thread.gmane.org/gmane.linux.gentoo.hardened/5658
I'm missing the proper information to tackle this (including some tests and the error message received).
