Bug 492558 - LIRC AVC denials
LIRC AVC denials
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks: 505490
  Show dependency treegraph
 
Reported: 2009-03-27 08:56 EDT by Torsten Rausche
Modified: 2009-11-18 08:04 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-18 08:04:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
AVC messages while opening and closing Totem in permissive mode (5.35 KB, text/plain)
2009-03-27 08:56 EDT, Torsten Rausche
no flags Details
AVC messages while starting lircd in permissive mode (1.79 KB, text/plain)
2009-03-27 09:17 EDT, Torsten Rausche
no flags Details

  None (edit)
Description Torsten Rausche 2009-03-27 08:56:43 EDT
Created attachment 337003 [details]
AVC messages while opening and closing Totem in permissive mode

Description of problem:
SELinux causes AVC denial messages if an application tries to connect to LIRC daemon.

Version-Release number of selected component (if applicable):
lirc-0.8.4a-2.fc10.x86_64
selinux-policy-targeted-3.5.13-53.fc10.noarch

How reproducible:
Always

Steps to Reproduce:
1. Make sure lircd is running
2. Activate LIRC plugin of Totem (for example)
3. Restart Totem
  
Actual results:
See attachment

Expected results:
No AVC denial messages

Additional info:
The attachment shows the output to audit.log in permissive mode. In enforcing mode Totem gives up earlier.
Comment 1 Torsten Rausche 2009-03-27 09:17:43 EDT
Created attachment 337009 [details]
AVC messages while starting lircd in permissive mode

I just noticed that there are also AVC messages when lircd starts.
Comment 2 Daniel Walsh 2009-03-27 09:33:20 EDT
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
Comment 3 Miroslav Grepl 2009-03-27 09:39:29 EDT
Dan, 

I agree and I am going to add lircd_t to permissive domain.
Comment 4 Miroslav Grepl 2009-03-30 12:24:24 EDT
Fixed in selinux-policy-3.5.13-54.fc10
Comment 5 Anthony Messina 2009-04-01 19:41:56 EDT
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)
Comment 6 Miroslav Grepl 2009-04-07 09:38:10 EDT
Fixed in selinux-policy-3.5.13-55.fc10
Comment 7 Tore Anderson 2009-05-31 14:57:50 EDT
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)
Comment 8 Miroslav Grepl 2009-06-01 08:46:25 EDT
Fixed in selinux-policy-3.6.12-44.fc11
Comment 9 David Batson 2009-10-12 08:46:44 EDT
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
"
Comment 10 Miroslav Grepl 2009-10-12 09:11:45 EDT
David,

what avc messages are you seeing in /var/log/audit/audit.log ?
Comment 11 David Batson 2009-10-12 10:20:21 EDT
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)
Comment 12 Miroslav Grepl 2009-10-13 07:47:42 EDT
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 ?
Comment 13 David Batson 2009-10-14 06:21:32 EDT
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
Comment 14 Miroslav Grepl 2009-10-16 08:07:09 EDT
(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
Comment 15 David Batson 2009-10-19 11:06:47 EDT
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)
Comment 16 David Batson 2009-10-20 05:01:11 EDT
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.
Comment 17 Bug Zapper 2009-11-18 06:37:10 EST
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
Comment 18 Daniel Walsh 2009-11-18 08:04:43 EST
Closing as closed in the current release.

Note You need to log in before you can comment on or make changes to this bug.