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-faa96b3fdd922004cdb988c1989e56191c257c01
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@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.
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 mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
