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/htm...
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)
Thanks -John
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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
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@redhat.com 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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
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@redhat.com 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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
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@redhat.com 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@redhat.com 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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
On 12/23/2015 12:09 AM, John W wrote:
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@redhat.com 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@redhat.com 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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
You can open a new issue on
https://github.com/fedora-selinux/selinux-policy/
or you could try to do a new pull request with a patch. See
https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute
for more details.
You can create a custom SELinux policy module with audit2allow Basically you set the policy to permissive, do your thing, run audit2allow to gen a policy, then import the policy and switch SELinux back to enforcing.
https://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e5619...
On 12/23/2015 05:24 AM, Miroslav Grepl wrote:
On 12/23/2015 12:09 AM, John W wrote:
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@redhat.com 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@redhat.com 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:
Running 'setenforce 0' causes it to start working
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/htm...
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@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
-- selinux mailing list selinux@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/selinux@lists.fedoraproject.org
-- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc.
You can open a new issue on
https://github.com/fedora-selinux/selinux-policy/
or you could try to do a new pull request with a patch. See
https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute
for more details.
selinux@lists.fedoraproject.org