Summary: SELinux is preventing /usr/sbin/snort-plain "ioctl" access on /dev/usbmon1. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by snort. It is not expected that this access is required by snort and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:snort_t:s0 Target Context system_u:object_r:usb_device_t:s0 Target Objects /dev/usbmon1 [ chr_file ] Source snort Source Path /usr/sbin/snort-plain Port <Unknown> Host (removed) Source RPM Packages snort-2.8.5.1-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-56.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.6-166.fc12.x86_64 #1 SMP Wed Dec 9 10:46:22 EST 2009 x86_64 x86_64 Alert Count 83 First Seen Tue 24 Nov 2009 06:18:34 PM CET Last Seen Mon 21 Dec 2009 05:57:08 PM CET Local ID 0d7bfc1f-522f-4611-be94-819f34b009b3 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1261414628.100:10951): avc: denied { ioctl } for pid=1274 comm="snort" path="/dev/usbmon1" dev=tmpfs ino=2924 scontext=system_u:system_r:snort_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file node=(removed) type=SYSCALL msg=audit(1261414628.100:10951): arch=c000003e syscall=16 success=yes exit=307200 a0=5 a1=9205 a2=0 a3=7 items=0 ppid=1273 pid=1274 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snort" exe="/usr/sbin/snort-plain" subj=system_u:system_r:snort_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-56.fc12,catchall,snort,snort_t,usb_device_t,chr_file,ioctl audit2allow suggests: #============= snort_t ============== allow snort_t usb_device_t:chr_file ioctl;
Do you have a network device attached to usbmon1?
no network device
What usb device is as /dev/usbmon1
*** Bug 551079 has been marked as a duplicate of this bug. ***
Why is snort touching usb devices?
/dev/usbmon1 "is not a regular file" a further access was denied usb devices connected: - mouse device - /dev/sdb 500GB hard disk, unmounted generally - /dev/sdc multi flash reader, mounted but generally hollow Selinux status - system default enforcing mode "permissive" - current enforcing mode "permissive" When/why snort is touching usb devices is not apparent in the course.
I was hoping Dennis could give us some insight.
*** Bug 552014 has been marked as a duplicate of this bug. ***
*** Bug 552013 has been marked as a duplicate of this bug. ***
*** Bug 552011 has been marked as a duplicate of this bug. ***
*** Bug 552009 has been marked as a duplicate of this bug. ***
*** Bug 552903 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Yes, close this bug; the newest Fedora versions are ever in use, anyway. Thanks.