On 12/22/2015 06:46 AM, John W wrote:
> 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...
Could you open a new bug against selinux-policy component with these
details?
Thank you.
>
> 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
>
--
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
