Bug 492558

Created attachment 337009 [details]
AVC messages while starting lircd in permissive mode

I just noticed that there are also AVC messages when lircd starts.

Miroslav add


files_read_etc_files(lircd_t)

files_list_var(lircd_t)
files_manage_generic_locks(lircd_t)
files_read_all_locks(lircd_t)

Might want to make this a permissive domain for now.

Not sure what it is doing in the lock directory, seems a little strange.

Torsten 

You can add these rules for now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Dan, 

I agree and I am going to add lircd_t to permissive domain.

Fixed in selinux-policy-3.5.13-54.fc10

Using the selinux-policy-3.5.13-54.fc10 from koji, and using MythTV, I get:

type=AVC msg=audit(1238628880.110:27): avc:  denied  { read write } for  pid=2190 comm="lircd" name="lirc0" dev=tmpfs ino=5801 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1238628880.110:27): arch=c000003e syscall=2 success=yes exit=7 a0=7fff4793aef8 a1=2 a2=0 a3=4000 items=0 ppid=1 pid=2190 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lircd" exe="/usr/sbin/lircd" subj=system_u:system_r:lircd_t:s0 key=(null)

type=AVC msg=audit(1238629000.981:36): avc:  denied  { write } for  pid=2190 comm="lircd" path="/dev/lirc0" dev=tmpfs ino=5801 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1238629000.981:36): arch=c000003e syscall=16 success=yes exit=0 a0=7 a1=40046913 a2=7fff47938dac a3=7fff47938f20 items=0 ppid=1 pid=2190 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lircd" exe="/usr/sbin/lircd" subj=system_u:system_r:lircd_t:s0 key=(null)

Fixed in selinux-policy-3.5.13-55.fc10

I gets lot of these (one per second) in the setroubleshoot browser in a current rawhide as of 31. may 2009:

Summary:

SELinux is preventing lircd (lircd_t) "getattr" access to device /dev/lirc0.

Detailed Description:

SELinux has denied the lircd (lircd_t) "getattr" access to device /dev/lirc0.
/dev/lirc0 is mislabeled, this device has the default label of the /dev
directory, which should not happen. All Character and/or Block Devices should
have a label. You can attempt to change the label of the file using restorecon
-v '/dev/lirc0'. If this device remains labeled device_t, then this is a bug in
SELinux policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If you look at the other similar devices labels, ls -lZ /dev/SIMILAR,
and find a type that would work for /dev/lirc0, you can use chcon -t
SIMILAR_TYPE '/dev/lirc0', If this fixes the problem, you can make this
permanent by executing semanage fcontext -a -t SIMILAR_TYPE '/dev/lirc0' If the
restorecon changes the context, this indicates that the application that created
the device, created it without using SELinux APIs. If you can figure out which
application created the device, please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this application.

Allowing Access:

Attempt restorecon -v '/dev/lirc0' or chcon -t SIMILAR_TYPE '/dev/lirc0'

Additional Information:

Source Context                system_u:system_r:lircd_t:s0
Target Context                system_u:object_r:device_t:s0
Target Objects                /dev/lirc0 [ chr_file ]
Source                        lircd
Source Path                   /usr/sbin/lircd
Port                          <Unknown>
Host                          wrath.fud.no
Source RPM Packages           lirc-0.8.5-1.pre2.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-39.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   device
Host Name                     wrath.fud.no
Platform                      Linux wrath.fud.no 2.6.29.4-167.fc11.i586 #1 SMP
                              Wed May 27 17:14:37 EDT 2009 i686 i686
Alert Count                   5036
First Seen                    sø. 31. mai 2009 kl. 12.24 +0000
Last Seen                     sø. 31. mai 2009 kl. 20.55 +0000
Local ID                      b1dface6-73d6-44fe-bae9-dc3b094d4e06
Line Numbers                  

Raw Audit Messages            

node=wrath.fud.no type=AVC msg=audit(1243796150.380:426): avc:  denied  { getattr } for  pid=1892 comm="lircd" path="/dev/lirc0" dev=tmpfs ino=7135 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=wrath.fud.no type=SYSCALL msg=audit(1243796150.380:426): arch=40000003 syscall=195 success=no exit=-13 a0=bff9eefc a1=bff9da1c a2=8e8ff4 a3=3 items=0 ppid=1 pid=1892 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lircd" exe="/usr/sbin/lircd" subj=system_u:system_r:lircd_t:s0 key=(null)

Fixed in selinux-policy-3.6.12-44.fc11

I was also affected with this bug.  My system is fully updated with selinux-policy-3.6.12-83.fc11

The solution in post #2 by Daniel Walsh worked for me.

"
You can add these rules for now using

# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
"

David,

what avc messages are you seeing in /var/log/audit/audit.log ?

I believe this is what you are looking for...

type=AVC msg=audit(1255178488.364:32269): avc:  denied  { open } for  pid=1639 comm="lircd" name="mouse1" dev=tmpfs ino=3815 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1255178488.364:32269): arch=40000003 syscall=5 success=no exit=-13 a0=80780e0 a1=0 a2=1000 a3=81125e8 items=0 ppid=1 pid=1639 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="lircd" exe="/usr/sbin/lircd" subj=system_u:system_r:lircd_t:s0 key=(null)

Ok and if you put the lircd to permissive domain and remove your local policy using

# semanage permissive -a lircd_t
# semodule -r mypol.pp

Does it also need to write to the mouse_device_t ?

Yes I believe so.  I had created and installed a semodule I named mlircd using information from the selinux faq, but that did not stop the selinux messages.  Then I created and installed semodule mypol as per the second comment in this bug report.  This did stop the selinux messages.  I thought that mypol had replaced mlircd, but I just now discovered both were installed.  I removed both semodules and now I get selinux messages as seen below.

Note that the command you posted is incorrect.  It should read:
# semodule -r mypol

type=AVC msg=audit(1255514966.995:18): avc:  denied  { read } for  pid=1651 comm="lircd" name="mice" dev=tmpfs ino=4704 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file
type=AVC msg=audit(1255514966.995:18): avc:  denied  { open } for  pid=1651 comm="lircd" name="mice" dev=tmpfs ino=4704 scontext=system_u:system_r:lircd_t:s0 tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file

(In reply to comment #13)
> Note that the command you posted is incorrect.  It should read:
> # semodule -r mypol

Yes, sorry about that.

> 
> type=AVC msg=audit(1255514966.995:18): avc:  denied  { read } for  pid=1651
> comm="lircd" name="mice" dev=tmpfs ino=4704
> scontext=system_u:system_r:lircd_t:s0
> tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file
> type=AVC msg=audit(1255514966.995:18): avc:  denied  { open } for  pid=1651
> comm="lircd" name="mice" dev=tmpfs ino=4704
> scontext=system_u:system_r:lircd_t:s0
> tcontext=system_u:object_r:mouse_device_t:s0 tclass=chr_file  

Fixed in selinux-policy-3.6.12-86.fc11

New problem. Trying to use pulseaudio-module-lirc-0.9.15-17.fc11.i586

I pasted the following into /etc/pulse/default.pa
.ifexists module-lirc.so
load-module module-lirc config=/etc/lircrc
.endif

as per: http://blog.mricon.com/2008/04/setting-up-apple-remote-control-with-f9.html

Now I get this selinux avc denial:

type=AVC msg=audit(1255963987.834:10): avc:  denied  { write } for  pid=1945 comm="pulseaudio" name="lircd" dev=tmpfs ino=10357 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lircd_sock_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1255963987.834:10): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfcab6d0 a2=47d0f0 a3=0 items=0 ppid=1941 pid=1945 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="pulseaudio" exe="/usr/bin/pulseaudio" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)

I think you can ignore my last comment.  I found out that I didn't need to add that section to /etc/pulse/default.pa afterall.

An odd finding though.  When the Opera browser is open, I lose my LIRC connection with the special keys of my Cyberlink Remote Control.  As soon as I close Opera, the Remote Control works again.  This is with Opera 10 final, build 4585, gcc4-qt3.  I do not experience this problem with Firefox or Epiphany.  AFAICT, this is not an selinux problem.

Thanks for resolving my previous issue.  I look forward to the selinux-policy-3.6.12-86.fc11 update.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Closing as closed in the current release.