Bug 371291 - egalax touchscreen hardware needs a policy to allow it to work
Summary: egalax touchscreen hardware needs a policy to allow it to work
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 8
Hardware: i386
OS: Linux
low
low
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-08 15:09 UTC by Rehan Khan
Modified: 2008-01-30 19:07 UTC (History)
1 user (show)

Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-01-30 19:07:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
raw selinux data used to create the policy (5.61 KB, text/plain)
2007-11-08 15:09 UTC, Rehan Khan
no flags Details
generated policy based on the procedure in the faq (linked from setroubleshooter) (649 bytes, text/plain)
2007-11-08 15:10 UTC, Rehan Khan
no flags Details
The compiled policy that can be loaded by selinux manager app. (1.92 KB, application/octet-stream)
2007-11-08 15:15 UTC, Rehan Khan
no flags Details
raw selinux data used to create the policy - updated (2.23 KB, text/plain)
2007-11-08 16:56 UTC, Rehan Khan
no flags Details
raw selinux data updated (4.11 KB, text/plain)
2007-11-08 17:25 UTC, Rehan Khan
no flags Details
generated policy - updated (586 bytes, text/plain)
2007-11-08 17:26 UTC, Rehan Khan
no flags Details
compiled policy - updated (1.76 KB, application/octet-stream)
2007-11-08 17:26 UTC, Rehan Khan
no flags Details
additional policy egalax7.te (177 bytes, text/plain)
2007-11-09 15:07 UTC, Rehan Khan
no flags Details
additional policy 2 egalax8.te (188 bytes, text/plain)
2007-11-09 15:07 UTC, Rehan Khan
no flags Details
selinux management app denial popping up when applying a new policy (logged in as root) (192 bytes, text/plain)
2007-11-09 15:15 UTC, Rehan Khan
no flags Details

Description Rehan Khan 2007-11-08 15:09:06 UTC
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
series).

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
config changes.


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

driver package 1.07 (X driver version is 1.10)

How reproducible:

everytime.

Steps to Reproduce:

1. Get driver from egalax site. Follow instructions to install the X driver.
2. restart X
3.
  
Actual results:

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.



Expected results:

A working touchscreen


Additional info:

Comment 1 Rehan Khan 2007-11-08 15:09:06 UTC
Created attachment 251561 [details]
raw selinux data used to create the policy

Comment 2 Rehan Khan 2007-11-08 15:10:42 UTC
Created attachment 251581 [details]
generated policy based on the procedure in the faq (linked from setroubleshooter)

Comment 3 Rehan Khan 2007-11-08 15:15:09 UTC
Created attachment 251591 [details]
The compiled policy that can be loaded by selinux manager app.

Comment 4 Daniel Walsh 2007-11-08 16:01:23 UTC
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?

egalax.cal

Also does it really need to write to these files or is this a bug in the device
driver?


Comment 5 Rehan Khan 2007-11-08 16:28:29 UTC
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 
character device.

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

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 :)

Rehan

Comment 6 Rehan Khan 2007-11-08 16:56:34 UTC
Created attachment 251811 [details]
raw selinux data used to create the policy - updated

Comment 7 Rehan Khan 2007-11-08 17:25:12 UTC
Created attachment 251871 [details]
raw selinux data updated

Comment 8 Rehan Khan 2007-11-08 17:26:21 UTC
Created attachment 251881 [details]
generated policy - updated

Comment 9 Rehan Khan 2007-11-08 17:26:55 UTC
Created attachment 251891 [details]
compiled policy - updated

Comment 10 Rehan Khan 2007-11-08 18:00:10 UTC
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 
labelling.
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

Section "InputDevice"
Identifier "EETI"
Driver "egalax"
Option "Device" "/dev/hiddev0"
Option "Parameters" "/etc/egalax.cal"
Option "ScreenNo" "0"
EndSection

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.



Comment 11 Rehan Khan 2007-11-08 18:04:20 UTC
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??



Comment 12 Daniel Walsh 2007-11-08 21:15:48 UTC
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.


Comment 13 Daniel Walsh 2007-11-08 21:16:24 UTC
BTW, this is not in a Fedora rpm, correct?


Comment 14 Rehan Khan 2007-11-09 14:58:04 UTC
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.

R

Comment 15 Rehan Khan 2007-11-09 15:05:30 UTC
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.

Thanks
rehan

Comment 16 Rehan Khan 2007-11-09 15:07:00 UTC
Created attachment 252841 [details]
additional policy egalax7.te

Comment 17 Rehan Khan 2007-11-09 15:07:41 UTC
Created attachment 252851 [details]
additional policy 2 egalax8.te

Comment 18 Rehan Khan 2007-11-09 15:15:45 UTC
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)

Comment 19 Rehan Khan 2007-11-09 15:20:45 UTC
(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.
> 
> Thanks
> rehan

Sorry, I don't think it is from the egalax driver but from the selinux
management app.


Comment 20 Daniel Walsh 2007-11-12 17:03:09 UTC
Ok as of selinux-policy-3.0.8-52.fc8

xserver will be able to create files/sock_files/directories in /var/run/xorg
and /var/lib/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


Comment 21 Rehan Khan 2007-11-18 02:30:14 UTC
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
that anywhere?

R



Comment 22 Daniel Walsh 2007-11-19 16:04:01 UTC
No.  One handy tool though is sesearch


sesearch --allow | grep xserver 

Will give you all the allow rules for xserver.  

Comment 23 Daniel Walsh 2008-01-30 19:07:09 UTC
Bulk closing a old selinux policy bugs that were in the modified state.  If the
bug is still not fixed.  Please reopen.


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