> Could you open a new bug against selinux-policy component with these details?
I tried many times, but bugzilla.redhat.com keeps giving me proxy
errors when I actually submit the bug.
Maybe it will work better next week (:
-John
On 12/22/15, Miroslav Grepl <mgrepl@xxxxxxxxxx> wrote:
> 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
