Summary: SELinux is preventing /usr/bin/python "read" access on mem. Detailed Description: [getSystemId has a permissive type (abrt_t). This access was not denied.] SELinux denied access requested by getSystemId. It is not expected that this access is required by getSystemId 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:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:memory_device_t:s0 Target Objects mem [ chr_file ] Source getSystemId Source Path /usr/bin/python Port <Unknown> Host (removed) Source RPM Packages python-2.6.2-2.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-46.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 Alert Count 3 First Seen Mon 16 Nov 2009 04:56:47 PM COT Last Seen Mon 16 Nov 2009 04:56:47 PM COT Local ID 46bd019b-1342-4aad-b762-7e2fab7db12b Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1258408607.803:24372): avc: denied { read } for pid=2209 comm="getSystemId" name="mem" dev=tmpfs ino=3193 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file node=(removed) type=AVC msg=audit(1258408607.803:24372): avc: denied { open } for pid=2209 comm="getSystemId" name="mem" dev=tmpfs ino=3193 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file node=(removed) type=AVC msg=audit(1258408607.803:24372): avc: denied { sys_rawio } for pid=2209 comm="getSystemId" capability=17 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tclass=capability node=(removed) type=SYSCALL msg=audit(1258408607.803:24372): arch=c000003e syscall=2 success=yes exit=4294967424 a0=16aa840 a1=0 a2=1b6 a3=0 items=0 ppid=2208 pid=2209 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="getSystemId" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-46.fc12,catchall,getSystemId,abrt_t,memory_device_t,chr_file,read audit2allow suggests: #============= abrt_t ============== allow abrt_t memory_device_t:chr_file { read open }; allow abrt_t self:capability sys_rawio;
This happened with selinux-policy and selinux-policy-targeted 3.6.2-46-f12 while using packagekit to remove a package. Apparently there was another yum process already running in the background and packagekit didn't have the chance to see it.
I have heard that this is being caused by a memory corruption in the abrt database. I have no idea why abrt or python/rpm would ever need this access. Would be a very bad idea to give it out.
*** Bug 539348 has been marked as a duplicate of this bug. ***
Even after updating selinux-policy-targeted 3.6.2-46-f12 , i thought it was quiet done and even i restarted. but still i get the bug.and it occurred 20 times since Mon Nov 23,2009 at 10.59.59 PM IST ------------------------------------******---------------------------------------- Summary: SELinux is preventing /usr/bin/python "read" access on mem. Detailed Description: [yum has a permissive type (abrt_t). This access was not denied.] SELinux denied access requested by yumdownloader. It is not expected that this access is required by yumdownloader 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:abrt_t:s0 Target Context system_u:object_r:memory_device_t:s0 Target Objects mem [ chr_file ] Source yum Source Path /usr/bin/python Port <Unknown> Host localhost.localdomain Source RPM Packages python-2.6.2-2.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-46.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.31.5-127.fc12.i686 #1 SMP Sat Nov 7 21:41:45 EST 2009 i686 i686 Alert Count 20 First Seen Mon 23 Nov 2009 10:59:59 PM IST Last Seen Tue 24 Nov 2009 09:08:58 PM IST Local ID bcb3359b-a4d9-453d-9129-13fd5f6272b1 Line Numbers Raw Audit Messages node=localhost.localdomain type=AVC msg=audit(1259077138.309:25462): avc: denied { read } for pid=7609 comm="yumdownloader" name="mem" dev=tmpfs ino=3140 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file node=localhost.localdomain type=AVC msg=audit(1259077138.309:25462): avc: denied { open } for pid=7609 comm="yumdownloader" name="mem" dev=tmpfs ino=3140 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:memory_device_t:s0 tclass=chr_file node=localhost.localdomain type=SYSCALL msg=audit(1259077138.309:25462): arch=40000003 syscall=5 success=yes exit=7 a0=8e64db8 a1=8000 a2=1b6 a3=8698800 items=0 ppid=6043 pid=7609 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yumdownloader" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0 key=(null)
also it mostly started to occur when i try to report bugs collected in automatic bug reporting tool.
I have been told this is being caused by a corruption in the abrt database, that occurred on an upgrade. The yum guys say there is no way yumdownloader would try to read /dev/mem. So I guess you need to clear out your abrt database.
*** Bug 541616 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 536949 ***
For Comment #6, Daniel Walsh. I am new guy. I want to know "how to clear out our abrt database?"
(In reply to comment #9) > For Comment #6, Daniel Walsh. I am new guy. I want to know "how to clear out > our abrt database?" You can stop abrtd, delete everything in /var/cache/abrt, restart abrtd. But note that it has been determined that abrt database corruption is _not_ the cause of this bug. Follow the discussion in bug 536949.