Red Hat Bugzilla – Bug 371291
egalax touchscreen hardware needs a policy to allow it to work
Last modified: 2008-01-30 14:07:09 EST
Description of problem:
egalax touchscreen hardware (present on some HP,Compaq and Dells tablet PC's)
installs itself as a hid device. Using the software from the egalax site
(www.eeti.com.tw) provides the X driver plus the calibration tools to make the
touchscreen fully function. In an unmodified SELinux targetted enforcing policy
fedora 8 system installation of the X driver crashes the greeter and also
crashes X if started from the commandline (startx).
After much frustration and hair pulling and looking at lots of weird text thrown
out by SELinux if cobbled together an SELinux policy which allows the touch
screen to work (including the calibration tool).
This policy applies to a touchscreen that udev loads as hiddev0. I have attached
the raw data and the te file I used to fix the problem on my laptop (hp tx1000
I am pretty sure that this policy only applies to the egalax driver and does not
allow anything from other systems.
The issues I can see (and would be grateful for any assistance) are:
1) The driver file is called egalax_drv.so and is located in
/usr/lib/X11/modules/input. the driver is loaded by X when it starts up. However
the denials refer to X and not the driver. So the policy applies to X as a
whole. Is this sufficient or does this need to be more granular (ie going right
down to the driver rather than applying to X as a whole)?
2) The policy is quite specific to a touch screen presented in /dev as hiddev0.
This might be too specific as the touch screen might show up on another device
name when installed on different hardware (e.g. /dev/hiddev1) or if the hardware
Version-Release number of selected component (if applicable):
driver package 1.07 (X driver version is 1.10)
Steps to Reproduce:
1. Get driver from egalax site. Follow instructions to install the X driver.
2. restart X
If the greeter is running it will crash and restart ad infinitum.
If x is being manually started then it will lock up on start.
A working touchscreen
Created attachment 251561 [details]
raw selinux data used to create the policy
Created attachment 251581 [details]
generated policy based on the procedure in the faq (linked from setroubleshooter)
Created attachment 251591 [details]
The compiled policy that can be loaded by selinux manager app.
Looks like the driver is trying to write to files in /etc and under /lib or
/usr/lib. What is the path to these files?
Also does it really need to write to these files or is this a bug in the device
The driver needs to read/write to /etc/egalax.cal. This is the config file
generated which stores the touch screen calibration data.
The rest of the operations are to /dev/hiddev0 which is the touchscreen
The driver is located in the Xorg driver directory which is
in /usr/lib/X11/modules/input. this might have been an issue when I was trying
to get this going early on a I just copied the file to the directory. I needed
to run a restorecon to apply the correct selinux policy to the copied driver
Perhaps some of the denials were from before I had applied the restorecon
to /usr/lib/X11/modules/input. Let me reset things back and try the policy
again. It was 5am when I finally had to give up trying to make the driver work
and take notice of the AVC denial warnings. Up until that point SELinux seemed
too scary to tackle :)
Created attachment 251811 [details]
raw selinux data used to create the policy - updated
Created attachment 251871 [details]
raw selinux data updated
Created attachment 251881 [details]
generated policy - updated
Created attachment 251891 [details]
compiled policy - updated
Thanks for the pointers Daniel. There was some 'historical' policy stuff in the
original submission. The updated policy should be close to a final.
The driver installation procedure should be something like this (in addition to
the instructions that come with the driver):
1) copy the egalax_drv.so file to /usr/lib/xorg/modules/input directory
2) run "restorecon /usr/lib/xorg/modules/input/* -v" to update the selinux
3) create a blank calibration file "touch /etc/egalax.cal"
4) run "restorecon /etc/* -v" to update the selinux labelling.
5) add the line
InputDevice "EETI" "SendCoreEvents"
to the /etc/X11/xorg.conf ServerLayout section.
6) add the section
Option "Device" "/dev/hiddev0"
Option "Parameters" "/etc/egalax.cal"
Option "ScreenNo" "0"
somewhere sensible in the /etc/X11/xorg.conf.
7) Import the policy : semodule -i egalax.pp
8) Setenforce 0 from a terminal
9) Restart X
10) Make sure SETroubleshooter has no new enties. If clear then the driver is
ready to be used. Reboot or setenforce 1 and restart X. If not then something
may have been missed from the policy.
Step 3 and 4 are required because if you don't do this manually the TouchKit
utility will create the file using selinux labelling of the logged in user. If
selinux is enforced this will prevent the file from being created. It also
reduces a policy line that would be needed just for this step.
To test this use "setenforce 0". The driver does not fail gracefully if it
can't do something and your whole Desktop is properly broken. To disable the
driver # comment out the InputDevice line that was added to the ServerLayout
section of the xorg.conf.
BTW I have pointed the egalax tech support to this bug. I guess it would be
useful to know if this policy is something that gets put into Fedora or if it
should be added to the driver distribution??
The Original policy you wrote is insecure. You really do not want xserver
writing etc_t, since lots of config files including /etc/passwd could be
overwritten. So a better solution would be to move this file to /var/lib/xorg
or /var/run/xorg if maintaining the file from one run to the other is not important.
/etc should be treated as a read/only partition.
Why is the device driver creating a fifo_file in /dev also? This should be
created in /var/run.
I will add policy to allow the xserver to r/w usb_device_t.
Current targeted policy for Fedora 8 should allow xserver to run unconfined so
these problems will largely dissapear, but it would be good to fix the device
driver to use better directories for other confined policies to work.
BTW, this is not in a Fedora rpm, correct?
Well the long response i wrote last night got killed with the server failure you
guys had last night :(
The support chaps at egalax have been following the thread and I have had some
very positive responses from them. It's really great that they are keen to fix
things up to work with selinux.
Regarding writing to etc. The touchscreen calibration data is (by default)
written to a file in etc called egalax.cal. If this file does not exist when the
driver starts it creates it in etc. This is configurable in the Section
statements in xorg.conf so it can be put anywhere. It is created by the driver
if it doesn't exist already. Then a userland tool writes data to it after a
calibration process. This data needs to be maintained as once the touchscreen is
calibrated it does not need to be done again for some time. If the egalax.cal
file is located in /var/lib/xorg will it still be accessible from the userland
tool (read, write, create, delete) for later recalibration runs and the driver?
The userland tool is a gui application.
The fifo was created where the real device node was (/dev/hiddev0). The
developer has suggested creating it in /var/run per your suggestion. Will this
have any issues with the hiddev0 device with relation to selinux targeted
policy? (data from hiddev0 <--> egalax X driver <--> /var/run/egalax_fifo <-->
userland tool)? (I'm not an expert on this, the developers are in Taiwan so I
guess their first language is not English. I am just trying to facilitate the
dialogue as I have a machine running fedora with an egalax touchscreen).
I am trying to get this to work with Fedora 8 test 3 fully updated (so I guess
it is fedora 8 final with the latest Policy).
This driver is not rpmised at the moment. Actually it should be fairly straight
forward to do. If the developers want they can submit the driver to Xorg
(probably the best place) perhaps by losening their licensing. There are many
posts about users trying to get the driver to work on fedora out on the net
(with varying degrees of success). I guess people who disable selinux have had
more success but they don't specifically note this. The tx1000 laptop from HP is
dirt cheap for a tablet pc with this amount of functionality. I am sure there
will be a ton of people who will want this to work out of the box.
So in summary if the calibration file is moved to /usr/lib/xorg and the fifo is
moved to /var/run the driver should fit nicely with the Linux standard file
locations and an selinux system (including fc6 and fc7)?
Thanks for taking the time to review this Dan.
I also have a couple of other selinux avc denials come up. I have attached them
as egalax7.te and egalax8.te. I'm not sure egalax7.te is necessary as only
applying egalax8.te seems to fix the problem and there don't seem to be any more
On a side note I am getting another denial. I think it is related to the egalax
driver. It happens when I load a policy file in the policy module in selinux
management. After a long wait the policy loads (i think) but the denial pops up
in troubleshooter. I have attached this as selinuxmanagement.te.
Created attachment 252841 [details]
additional policy egalax7.te
Created attachment 252851 [details]
additional policy 2 egalax8.te
Created attachment 252861 [details]
selinux management app denial popping up when applying a new policy (logged in as root)
I have run the raw data through audit2allow to get something more human
readable (at least for me)
(In reply to comment #15)
> I also have a couple of other selinux avc denials come up. I have attached them
> as egalax7.te and egalax8.te. I'm not sure egalax7.te is necessary as only
> applying egalax8.te seems to fix the problem and there don't seem to be any more
> avc denials.
> On a side note I am getting another denial. I think it is related to the egalax
> driver. It happens when I load a policy file in the policy module in selinux
> management. After a long wait the policy loads (i think) but the denial pops up
> in troubleshooter. I have attached this as selinuxmanagement.te.
Sorry, I don't think it is from the egalax driver but from the selinux
Ok as of selinux-policy-3.0.8-52.fc8
xserver will be able to create files/sock_files/directories in /var/run/xorg
These will be labeled xserver_var_run_t and xserver_var_lib_t.
User space tools should be able to read/write /var/run/xorg directory. A future
update of xorg will crea
te these directories automatically.
Fixed in selinux-policy-3.0.8-52.fc8
Thanks. I have recently chased egalax to see if they were going to update their
driver. It seems that they had some code issues with the changes and have
decided to try a shared memory model for the fifo buffer (or something like that).
Is there some human readable documentation on what can and can't access this or
No. One handy tool though is sesearch
sesearch --allow | grep xserver
Will give you all the allow rules for xserver.
Bulk closing a old selinux policy bugs that were in the modified state. If the
bug is still not fixed. Please reopen.