Description of problem: Summary SELinux is preventing /sbin/pam_console_apply (pam_console_t) "getattr" to /dev/fb0 (device_t). Detailed Description SELinux denied access requested by /sbin/pam_console_apply. It is not expected that this access is required by /sbin/pam_console_apply 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 Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/fb0, restorecon -v /dev/fb0 If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:pam_console_t:s0-s0:c0.c1023 Target Context system_u:object_r:device_t:s0 Target Objects /dev/fb0 [ file ] Affected RPM Packages pam-0.99.8.1-17.fc8 [application] Policy RPM selinux-policy-3.0.8-84.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name plugins.catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 athlon Alert Count 64 First Seen Wed 23 Jan 2008 11:02:37 PM PST Last Seen Mon 25 Feb 2008 08:22:31 AM PST Local ID 79c5c44f-94a8-4b21-8d28-f98fcbb1e25a Line Numbers Raw Audit Messages avc: denied { getattr } for comm=pam_console_app dev=tmpfs egid=500 euid=0 exe=/sbin/pam_console_apply exit=-13 fsgid=500 fsuid=0 gid=500 items=0 path=/dev/fb0 pid=2180 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023 sgid=500 subj=system_u:system_r:pam_console_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Your browser's knowledgebase tells me that it could be a attempted intrusion. If there's a way to automate the voluntary reporting of such attempts, I'm all for it. Thanks
Strange /dev/fb0 should be labeled framebuf_device_t matchpathcon /dev/fb0 /dev/fb0 system_u:object_r:framebuf_device_t:s0 What does matchpathcon of this device show you? Do you know how this device was created? IE Did udev create it? udev should have labeled it correctly if it created it.
Sorry: I have no idea how this happened. I've been hacked before (quite a few times in Windows before I started using Linux in '03. I'm a BSA/DB Developer/turned PM Type, worked in a Unix environment before. I'm no SysAdmin; but under instruction, can make some queries into the system. I tried to call matchpathcon; but had "no joy" on a Sys Terminal. Checked my packages; and came up short there too. From googling around, figure matchpathcon pkgs should be available. This is a generic Fedora 8 install, with Livna repos included. I mounted my NTFS drive to access its files. I religiously process pkg updates (including this mornings). I've bug reports out to Mozilla(Firefox), NoScript addon, and Tor people for having series of crashes. Have other addons as well. I've a trouble call out on Fedora Forums as well - I've a dual boot system (w/XP, each OS has its hard drive). Tried to install Solaris; and found out that most of my Fedora Drive (non-boot partition)is "unformatted". BTW, I'm still get these reports (had several a minute after I opened a message in gmail). If any of this helps this helps a bit - this sounds like another security breach, so please advise as to next course of actions, so you can complete the forensics on this puppy. I've a Live CD available, so If you wish, I can surf the web, etc off of it. Standing by - thanks
Does restorecon -v /dev/fb0 fix the labeling?
Negative - all I'm getting is "Command not found" Do you want me to install pkgs that enable matchpathcon and restorecon? If so, what are their names? thanks.
You need them in the path /sbin/restorecon -r -v /dev/fb0 /usr/sbin/matchpathcon /dev/fb0 or execute su - Which should add the path.
Good Morning, Daniel: Here's the result. [root@localhost robertgray86]# /sbin/restorecon -r -v /dev/fb0 [root@localhost robertgray86]# /usr/sbin/matchpathcon /dev/fb0 /dev/fb0 system_u:object_r:device_t:s0 I've also noticed that with the exception of the boot partition, the rest of my Fedora Drive is unformatted. Could this be related? Thanks; and regards
I don't know what you mean by unformated? Are you saying there are no file contexts?
Nah - just found out that it was an LVM issue - not to worry - thanks. BTW, I've several other entries in the troubleshooter browser. would you like to see/scan the entire compilation? Regards,
Yes
Created attachment 296241 [details] Just like the name - current compilation of setroubleshoot log entries. Done. Hope this helps. I'll be standing by if you need anything else. Thank you.
Looks like you moved a bunch of files to /tmp that tmpreaper would like to delete. /tmp/vbox.0/... If you remove this directory tree the avc's/setroubleshoot windows should stop.
Great...er...thanks. Don't recall voluntarily moving files to /tmp; but may I have some explicit (as in - I am not a SysAdmin explicit)instructions on how to: 1)clean up /tmp so the "tmp reaper" could do its job (e.g., which ones to keep, which ones to trash); and 2)Remove the directory tree in question; and from where. I ass/u/me that may be a VirtualBox issue (vbox.0?), so I'll try to inquire the VirtualBox people about any conflicts with "SELinux" functionalities. I've had these alerts prior to installing VirtualBox, though. If you want to send the instructions offline (direct email), and/or take it to the Fedora Forum (for bugzilla's and instructions for us m00bs), I'm all ears. Thanks in advance. Thanks
Usually I pontificate on danwalsh.livejournal.com. If you go read this blog you will no more aboue selinux then you ever care too. I like to call the blog SELinux for dummies.