Hi,
Yes, I found about about the "dontaudit" trickery; thanks for mentioning it.
So, following that path, I did eventually uncover a string of
additional denials, and included them in my custom policy.
So, "amixer" can be run from acpid now, although pulseaudio is the
next pain in by backside (apparently even root cannot use sound
without extra steps). But that's for another list (:
For the record, this is the full set of denials:
------------
type=AVC msg=audit(1450643943.351:1071): avc: denied { read } for
pid=17124 comm="amixer" name="controlC0" dev="devtmpfs" ino=13431
scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
permissive=0
type=AVC msg=audit(1450645877.188:1497): avc: denied { open } for
pid=24344 comm="amixer" path="/dev/snd/controlC0" dev="devtmpfs"
ino=13431 scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
permissive=0
type=AVC msg=audit(1450646449.252:1604): avc: denied { ioctl } for
pid=26283 comm="amixer" path="/dev/snd/controlC0" dev="devtmpfs"
ino=13431 scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
permissive=0
type=AVC msg=audit(1450649676.646:2155): avc: denied { getattr } for
pid=6407 comm="amixer" path="/usr/share/alsa/alsa.conf" dev="sda5"
ino=2231592 scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:alsa_etc_rw_t:s0 tclass=file permissive=0
type=AVC msg=audit(1450650193.910:2306): avc: denied { read } for
pid=8370 comm="amixer" name="alsa.conf" dev="sda5" ino=2231592
scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:alsa_etc_rw_t:s0 tclass=file permissive=0
type=AVC msg=audit(1450650622.897:2416): avc: denied { open } for
pid=9899 comm="amixer" path="/usr/share/alsa/alsa.conf" dev="sda5"
ino=2231592 scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:alsa_etc_rw_t:s0 tclass=file permissive=0
type=AVC msg=audit(1450651145.995:2552): avc: denied { write } for
pid=11799 comm="amixer" name="controlC0" dev="devtmpfs" ino=13431
scontext=system_u:system_r:apmd_t:s0
tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
permissive=0
------------
And here is the .te file that audit2allow created:
------------
module allow_acpid_access_sound 1.0;
require {
type alsa_etc_rw_t;
type sound_device_t;
type apmd_t;
class chr_file { write read ioctl open };
class file { read getattr open };
}
#============= apmd_t ==============
allow apmd_t alsa_etc_rw_t:file { read getattr open };
allow apmd_t sound_device_t:chr_file write;
allow apmd_t sound_device_t:chr_file { read ioctl open };
------------
I don't know if this is 100% proper, but I guess it's working, and
seems reasonably restrained...
Thanks
-John
On 12/20/15, Miroslav Grepl <mgrepl@xxxxxxxxxx> wrote:
> On 12/20/2015 11:09 PM, John W wrote:
>> Hello,
>>
>> I'm trying to control the system volume on my laptop using the special
>> volume keys on the keyboard.
>> Pressing the keys generates acpi events, so I am using acpid to handle
>> them.
>> I have a script at /etc/acpid/actions that runs, no problem.
>>
>> However, the script does not work when run via the acpid daemon. In
>> particular the "amixer" command it uses to alter the volume fails.
>>
>> It works fine when run manually, and fine when run as root.
>>
>> I suspect SELinux because:
>>
>> 1) Running 'setenforce 0' causes it to start working
>>
>> 2) I see denials in the audit.log:
>>
>> type=AVC msg=audit(1450643943.351:1071): avc: denied { read }
>> for pid=17124 comm="amixer" name="controlC0" dev="devtmpfs" ino=13431
>> scontext=system_u:system_r:apmd_t:s0
>> tcontext=system_u:object_r:sound_device_t:s0 tclass=chr_file
>> permissive=0
>>
>> First question: Should I be opening a bug report about this? This page
>> indicates maybe so:
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Allowing_Access_audit2allow.html
>>
>> Now, I have gone ahead trying to get this working using audit2allow.
>> Indeed, I have created a policy package, with these bits:
>> allow apmd_t sound_device_t:chr_file ioctl;
>> allow apmd_t sound_device_t:chr_file { read open };
>>
>> I installed the .pp file with "semodule -i", and it shows up in "semodule
>> -l".
>>
>> Now, no audit.log entries are produced. But it still doesn't work!
>> It *does* work when I use "setenforce 0", but apparently my custom
>> policy package, while it does silence the audit log, does not fix the
>> issue.
>>
>> So, my second question: What else could be going on?
>> Wouldn't any denials show up in the log?
>>
>> I would like to solve this in a focused way, rather than turning off
>> SELinux entirely, but currently that seems to be the only thing that
>> works, and I can't see how to proceed...
>>
>> My system info, if you want:
>>
>> $ uname -a
>> Linux biglap.home.lan 3.18.9-200.fc21.x86_64 #1 SMP Mon Mar 9
>> 15:10:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
>> $ cat /etc/fedora-release
>> Fedora release 21 (Twenty One)
>
> Thank you for testing your local policy. Could you please try to run
>
> # semodule -DB
>
> to turn dontaudit rules off, re-test it and
>
> # ausearch -m avc -ts recent
>
>>
>> Thanks
>> -John
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
>>
>
>
> --
> Miroslav Grepl
> Senior Software Engineer, SELinux Solutions
> Red Hat, Inc.
>
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
