Bug 703190 - lircd works when launched from prompt only
Summary: lircd works when launched from prompt only
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 14
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-09 15:36 UTC by Mark Mayfield
Modified: 2011-11-23 22:44 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-11-23 22:44:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Mark Mayfield 2011-05-09 15:36:20 UTC
Description of problem:
lirc works only if launched from command as root or if client is run as root

Version-Release number of selected component (if applicable):
lircd 0.9.0

How reproducible:
start lirc service using --driver=usbx --device=/dev/ttyUSB0


Steps to Reproduce:
1. configure /etc/sysconfig/lirc with usbx driver and ttyUSB0 device
2. use properly configure /etc/lirc/lircd.conf
3. run service lirc start
4. create .lircrc for client
5. run client as regular user
  
Actual results:
Lirc starts but is not allowed acces to /dev/ttyUSB0


Expected results:
Lirc functions properly

Additional info:
also tried to run lirc with a logfile option but that does not work either.
lircd -L log.txt - gives invalid option even though it is listed in the man page

from dmesg
[    7.993808] ftdi_sio 2-1:1.0: FTDI USB Serial Device converter detected
[    7.995671] usbcore: registered new interface driver ftdi_sio
[    7.995673] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

messages when launched from command line
May  9 09:45:33 localhost lircd-0.9.0[3242]: lircd(usbx) ready, using /var/run/lirc/lircd
May  9 09:45:40 localhost lircd-0.9.0[3242]: accepted new client on /var/run/lirc/lircd
May  9 09:45:41 localhost pulseaudio[2240]: ratelimit.c: 2 events suppressed
May  9 09:46:31 localhost lircd-0.9.0[3242]: removed client
May  9 09:49:35 localhost lircd-0.9.0[3242]: caught signal

messages when service started
May  9 09:49:35 localhost lircd-0.9.0[3653]: lircd(usbx) ready, using /var/run/lirc/lircd
May  9 09:49:39 localhost lircd-0.9.0[3653]: accepted new client on /var/run/lirc/lircd
May  9 09:49:39 localhost lircd-0.9.0[3653]: Could not open the '/dev/ttyUSB0' device
May  9 09:49:39 localhost lircd-0.9.0[3653]: Failed to initialize hardware
May  9 09:50:30 localhost lircd-0.9.0[3653]: removed client

/etc/sysconfig/lirc
# Note: in addition to these parameters, you need to have working    -*- sh -*-
# configuration file for lircd (and lircmd if enabled).

# Options to lircd(8).  Typically, this will be empty, as which driver to use
# should be specified using the LIRC_DRIVER variable below.
LIRCD_OPTIONS=""

# The infrared receiver (and/or transmitter) driver to be used by lircd(8),
# similar to passing "-H driver" to lircd(8).
# Run "/usr/sbin/lircd -H help" to get a listing of supported drivers.
LIRC_DRIVER="usbx"

# Which lirc device will be used by lircd(8).
# This is the same as passing "-d device" to lircd.
# An empty value will use the default /dev/lirc0 device.
LIRC_DEVICE="/dev/ttyUSB0"

# If "yes", the init script will try to start lircmd(8) too.
ENABLE_LIRCMD="no"

# Options to lircmd(8).
LIRCMD_OPTIONS=""

Comment 1 Jarod Wilson 2011-05-09 19:03:04 UTC
When lircd is run from a console and works, is that as root, or as your desktop user? In any case, this sounds like a permissions issue on /dev/ttyUSB0, which isn't really something lirc has anything to do with... What does 'ls -lZ /dev/ttyUSB0' show?

Comment 2 Mark Mayfield 2011-05-09 19:21:30 UTC
I use sudo to run it from the console. But when I run it from the console my client program (vlc) is able to use lirc. When I use service management it is not. Either way the process shows up to be owned by root and the permissions on /dev/ttyUSB0 are the same.


ls -lZ /dev/ttyUSB0
crw-rw----. root dialout system_u:object_r:tty_device_t:s0 /dev/ttyUSB0

I thought it sounded like a permission issue but could not determine why it would work from console and not service script

I do not get any avc denials for ttyUSB0. I had some for lircd.conf and a couple of other things but I resolved those.

Comment 3 Mark Mayfield 2011-05-18 12:28:54 UTC
I have no problem reclassifying it from lirc to another component, I just don't know where the problem is coming from. Usually lirc has modules that have to be loaded but my ir receiver has an independent module, ftdi_sio. But it is a supported module and I have not had these problems with it before, or with the ttyUSB0 device.

Comment 4 Jarod Wilson 2011-05-28 20:58:45 UTC
Sorry for the lack of reply, but I haven't a clue where to point you.

Comment 5 Mark Mayfield 2011-08-29 22:22:55 UTC
resolved
I'm sure I set SELINUX to permissive before and it did not work but after running some updates and trying again the issue has been resolved. This time when I set selinux to permissive and ran the client I got a SELINUX troubleshooter notification, the details helped me fix the problem. I had to set the following boolean.

sudo setsebool -P allow_daemons_use_tty 1

why the troubleshooter does not issue a denial when SELINUX is enabled I don't understand. It's also puzzling why it would work when launched from the prompt under the exact same SELINUX environment it did not work from with the service script. LIRCD is a daemon whether started from a service or the command line, isn't it?

maybe the SELINUX team should be informed of this?
Also is it possible to have the lirc context so that it can use a tty device without allowing all daemons?
I tried to create a policy module to this with 

cat /var/log/audit/audit.log | audit2allow -M mylirc
semodule -i mylirc.pp

It did not work

I did not close the bug to ensure this would be read. Please feel free to close the issue upon reviewing

Comment 6 Mark Mayfield 2011-09-25 16:10:49 UTC
I moved this over to SELINUX since it is where the problem was. I have it working but thought the SELINUX team might want to have a peek at it.

Comment 7 Dominick Grift 2011-09-25 16:43:06 UTC
SELinux expects tty usb device nodes in: /dev/usb/, not sure why yours is /dev/ttyUSB0

/dev/ttyUSB0 is mislabelled. It currently is labelled unallocated tty (tty_device_t) but it should be labelled usb tty device (ttyusb_device_t)

Nonetheless even if it would be /dev/usb/ttyUSB0 (usbtty_device_t), lircd would still be denied access because lircd is currently not allowed to use usb tty devices.

There is a rule that allows lircd to use generic usb devices. I have a feeling that this rule was added due to a similar mislabelled node.

So i my view we need to fix the labelling of tty usb devices (named filetrans?) and then allow lircd to use properly labelled tty usb device nodes instead of generic usb device nodes.

Comment 8 Dominick Grift 2011-09-25 17:02:26 UTC
Something like this ( i am sure that i have overlooked stuff );

diff --git policy/modules/kernel/terminal.fc policy/modules/kernel/terminal.fc
index 6727eb7..e398357 100644
--- policy/modules/kernel/terminal.fc
+++ policy/modules/kernel/terminal.fc
@@ -19,6 +19,7 @@
 /dev/slamr[0-9]+	-c	gen_context(system_u:object_r:tty_device_t,s0)
 /dev/tty		-c	gen_context(system_u:object_r:devtty_t,s0)
 /dev/ttySG.*		-c	gen_context(system_u:object_r:tty_device_t,s0)
+/dev/ttyUSB.*		-c	gen_context(system_u:object_r:usbtty_device_t,s0)
 /dev/vport[0-9]p[0-9]+  -c  gen_context(system_u:object_r:virtio_device_t,s0)
 /dev/xvc[^/]*		-c	gen_context(system_u:object_r:tty_device_t,s0)
 
diff --git policy/modules/kernel/terminal.if policy/modules/kernel/terminal.if
index ea0ff94..bf8b146 100644
--- policy/modules/kernel/terminal.if
+++ policy/modules/kernel/terminal.if
@@ -1308,6 +1308,26 @@
 
 ########################################
 ## <summary>
+##	Read from and write USB tty
+##	character device nodes.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain allowed access.
+##	</summary>
+## </param>
+#
+interface(`term_use_usb_ttys',`
+	gen_require(`
+		type usbtty_device_t;
+	')
+
+	dev_list_all_dev_nodes($1)
+	allow $1 usbtty_device_t:chr_file rw_chr_file_perms;
+')
+
+########################################
+## <summary>
 ##	Get the attributes of all tty device nodes.
 ## </summary>
 ## <param name="domain">
@@ -1971,6 +1991,16 @@
 	dev_filetrans($1, tty_device_t, chr_file, "ttySG7")
 	dev_filetrans($1, tty_device_t, chr_file, "ttySG8")
 	dev_filetrans($1, tty_device_t, chr_file, "ttySG9")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB0")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB1")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB2")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB3")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB4")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB5")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB6")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB7")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB8")
+	dev_filetrans($1, usbtty_device_t, chr_file, "ttyUSB9")
 	dev_filetrans($1, virtio_device_t, chr_file, "vport0p0")
 	dev_filetrans($1, virtio_device_t, chr_file, "vport0p1")
 	dev_filetrans($1, virtio_device_t, chr_file, "vport0p2")
diff --git policy/modules/services/lircd.te policy/modules/services/lircd.te
index a32fbe8..b37e4e0 100644
--- policy/modules/services/lircd.te
+++ policy/modules/services/lircd.te
@@ -45,7 +45,7 @@
 corenet_tcp_sendrecv_all_ports(lircd_t)
 corenet_tcp_connect_lirc_port(lircd_t)
 
-dev_rw_generic_usb_dev(lircd_t)
+dev_rw_generic_usb_dev(lircd_t) # not sure if this is really right.
 dev_read_mouse(lircd_t)
 dev_filetrans_lirc(lircd_t)
 dev_rw_lirc(lircd_t)
@@ -58,6 +58,7 @@
 files_read_all_locks(lircd_t)
 
 term_use_ptmx(lircd_t)
+term_use_usb_ttys(lircd_t)
 
 logging_send_syslog_msg(lircd_t)

Comment 9 Daniel Walsh 2011-09-26 19:24:45 UTC
Looks good to me, should be checked into F16 and back ported.

Comment 10 Dominick Grift 2011-09-26 19:58:12 UTC
http://git.fedorahosted.org/git/?p=selinux-policy.git;a=commitdiff;h=105865a08aaed4270d62ff44ca919b1ca1a93922

I do not know if back porting this change is such a good idea, since this may break anything depending on /dev/ttyUSB[0-9]+ character device nodes being labeled type tty_device_t.

Comment 11 Miroslav Grepl 2011-09-27 06:12:34 UTC
Let's test it for a while and then I could backport it.


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