Summary: SELinux is preventing /sbin/consoletype "read write" access to device /dev/536ep. Detailed Description: [consoletype has a permissive type (consoletype_t). This access was not denied.] SELinux has denied consoletype "read write" access to device /dev/536ep. /dev/536ep 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/536ep'. If this device remains labeled device_t, then this is a bug in SELinux policy. Please file a bg report. If you look at the other similar devices labels, ls -lZ /dev/SIMILAR, and find a type that would work for /dev/536ep, you can use chcon -t SIMILAR_TYPE '/dev/536ep', If this fixes the problem, you can make this permanent by executing semanage fcontext -a -t SIMILAR_TYPE '/dev/536ep' 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 against this application. Allowing Access: Attempt restorecon -v '/dev/536ep' or chcon -t SIMILAR_TYPE '/dev/536ep' Additional Information: Source Context unconfined_u:system_r:consoletype_t:s0 Target Context system_u:object_r:device_t:s0 Target Objects /dev/536ep [ chr_file ] Source consoletype Source Path /sbin/consoletype Port <Unknown> Host (removed) Source RPM Packages initscripts-9.02-1 Target RPM Packages Policy RPM selinux-policy-3.6.32-41.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name device Host Name (removed) Platform Linux (removed) 2.6.31.9-174.fc12.i686.PAE #1 SMP Mon Dec 21 06:04:56 UTC 2009 i686 i686 Alert Count 6 First Seen Sun 13 Dec 2009 09:17:50 PM CST Last Seen Sat 23 Jan 2010 02:11:39 PM CST Local ID d08c40b6-e21a-43f9-b076-b15955131bce Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1264277499.469:29): avc: denied { read write } for pid=2610 comm="consoletype" path="/dev/536ep" dev=tmpfs ino=12557 scontext=unconfined_u:system_r:consoletype_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file node=(removed) type=AVC msg=audit(1264277499.469:29): avc: denied { read write } for pid=2610 comm="consoletype" path="socket:[226568]" dev=sockfs ino=226568 scontext=unconfined_u:system_r:consoletype_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_dgram_socket node=(removed) type=SYSCALL msg=audit(1264277499.469:29): arch=40000003 syscall=11 success=yes exit=0 a0=97841f0 a1=9784250 a2=977cf20 a3=9784250 items=0 ppid=2609 pid=2610 auid=500 uid=0 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="consoletype" exe="/sbin/consoletype" subj=unconfined_u:system_r:consoletype_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-41.fc12,device,consoletype,consoletype_t,device_t,chr_file,read,write audit2allow suggests: #============= consoletype_t ============== allow consoletype_t device_t:chr_file { read write }; allow consoletype_t unconfined_t:unix_dgram_socket { read write };
I have updated selinux policy to latest available and have applied the suggested fix. I will boot newer kernel and report back if the problem persists, ie. kppp will trigger setroubleshoot, otherwise report back problem has been fixed.
As I booted to newer kernel, I saw the setroubleshoot star with the same message and against new selinux policy :( Intel 536EP card found pci 0000:05:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [root@localhost ~]# ls /dev/modem -l lrwxrwxrwx. 1 root root 10 2010-01-23 16:22 /dev/modem -> /dev/536ep [root@localhost ~]# ls /dev/536ep -l crw-rw-rw-. 1 root root 240, 1 2010-01-23 16:23 /dev/536ep [root@localhost ~]# ls -Z /dev/536ep crw-rw-rw-. root root unconfined_u:object_r:device_t:s0 /dev/536ep Should I try the audit2allow suggestions? I don't have very strong selinux skills :( I just apply many suggestions and advice from selinux experts :)
The problem is SELinux expects the /dev/536ep to be labeled usb_device_t matchpathcon /dev/536ep /dev/536ep system_u:object_r:usb_device_t:s0 Which udev should have done, if it created the device. If something else created the device it should have labeled it correctly. Do you know which process is creating the device?
Dan, Phillipe Vouters, maintainer of the Intel 536/537 Modem code, sent me this /* Antonio, The code which creates the /dev/536ep terminal device is coredrv/softserial.c when it calls tty_register_driver(&G.softserial_tty_driver); after it has set the following information: G.softserial_tty_driver.driver_name = SOFTSERIAL_DRIVER_NAME; G.softserial_tty_driver.name = SOFTSERIAL_DEVICE_NAME; Yours truly, -- sip:Vouters.Philippe IM: philvout (Yahoo!) http://vouters.dyndns.org/ Philippe Vouters (Fontainebleau/France) */ Hope this helps. Although I have not seen the sealerts anymore when I try KPPP, but just in case you need more information to see what causes this.
The question is, does the kernel create the device directly or is it created by udev. udev will label it correctly. If the kernel/device driver creates the device directly then that is a bug in the kernel/devicedriver. If you are seeing the device with the correct label, then maybe we can close this bug.
(In reply to comment #5) > The question is, does the kernel create the device directly or is it created by > udev. udev will label it correctly. If the kernel/device driver creates the > device directly then that is a bug in the kernel/devicedriver. > > If you are seeing the device with the correct label, then maybe we can close > this bug. The code from Phillipe Vouters makes the modem respond and dialout, It becomes a kernel module I believe, but am not sure :(, The device is created at bootup and like I have replied. When I use wvdial, I don't see the sealerts. But if I use kppp, then I saw it. I have updated selinux policy and I don't see the seaalert. Which should be the correct label if there is one? If the sealert is not there anymore, I do believe that we can close this bug.
It should be usb_device_t. There should never be a chr_file/blk_file labeled device_t.