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:
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? egalax.cal Also does it really need to write to these files or is this a bug in the device driver?
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
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 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.
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. R
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
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. > > Thanks > rehan Sorry, I don't think it is from the egalax driver but from the selinux management app.
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
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
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.