acpid cannot run 'amixer' due to SELinux issue?

[John W]

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/...

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

[Miroslav Grepl]

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/...
>  
>  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(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>   

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

[John W]

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(a)redhat.com&gt; 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/...
>>
>> 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(a)lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/[e-mail]
>>
>
>
> --
> Miroslav Grepl
> Senior Software Engineer, SELinux Solutions
> Red Hat, Inc.
>

[Miroslav Grepl]

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(a)redhat.com&gt; 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/...
> >>
> >> 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(a)lists.fedoraproject.org
> >> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >>
> >
> >
> > --
> > Miroslav Grepl
> > Senior Software Engineer, SELinux Solutions
> > Red Hat, Inc.
> >
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  http://lists.fedoraproject.org/admin/lists/[e-mail]
>   

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

[John W]

>  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(a)redhat.com&gt; 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(a)redhat.com&gt; 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/...
>>>>
>>>> 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(a)lists.fedoraproject.org
>>>>
http://lists.fedoraproject.org/admin/lists/[e-mail]
>>>>
>>>
>>>
>>> --
>>> Miroslav Grepl
>>> Senior Software Engineer, SELinux Solutions
>>> Red Hat, Inc.
>>>
>> --
>> selinux mailing list
>> selinux(a)lists.fedoraproject.org
>> http://lists.fedoraproject.org/admin/lists/[e-mail]
>>
>
>
> --
> Miroslav Grepl
> Senior Software Engineer, SELinux Solutions
> Red Hat, Inc.
>

[Miroslav Grepl]

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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/...
> >>>>
> >>>> 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(a)lists.fedoraproject.org
> >>>>
> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >>>>
> >>>
> >>>
> >>> --
> >>> Miroslav Grepl
> >>> Senior Software Engineer, SELinux Solutions
> >>> Red Hat, Inc.
> >>>
> >> --
> >> selinux mailing list
> >> selinux(a)lists.fedoraproject.org
> >> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >>
> >
> >
> > --
> > 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.


-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.

[Andy Bentley]

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-faa96b3fdd922004cdb988c1989e5...

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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/...
> >>>>>
> >>>>> 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(a)lists.fedoraproject.org
> >>>>>
> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >>>>>
> >>>>
> >>>> --
> >>>> Miroslav Grepl
> >>>> Senior Software Engineer, SELinux Solutions
> >>>> Red Hat, Inc.
> >>>>
> >>> --
> >>> selinux mailing list
> >>> selinux(a)lists.fedoraproject.org
> >>> http://lists.fedoraproject.org/admin/lists/[e-mail]
> >>>
> >>
> >> --
> >> 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.
>
>