Summary: SELinux is preventing /usr/bin/python "write" access on /var/cache/abrt. Detailed Description: While running this command: # semanage fcontext -t tmp_t '/t(/.*)?' Can't create lock file '/var/cache/abrt/pyhook-1255454681-6327.lock': Permission denied SELinux denied access requested by semanage. It is not expected that this access is required by semanage 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 unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c102 3 Target Context system_u:object_r:abrt_var_cache_t:s0 Target Objects /var/cache/abrt [ dir ] Source semanage Source Path /usr/bin/python Port <Unknown> Host (removed) Source RPM Packages python-2.6.2-2.fc12 Target RPM Packages abrt-0.0.9-2.fc12 Policy RPM selinux-policy-3.6.32-25.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.1-56.fc12.x86_64 #1 SMP Tue Sep 29 16:16:22 EDT 2009 x86_64 x86_64 Alert Count 3 First Seen Tue 13 Oct 2009 07:23:58 PM CEST Last Seen Tue 13 Oct 2009 07:24:41 PM CEST Local ID e384502a-904d-415b-8f15-48531c125f08 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1255454681.173:35176): avc: denied { write } for pid=6327 comm="semanage" name="abrt" dev=sdc4 ino=57350 scontext=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1255454681.173:35176): arch=c000003e syscall=2 success=no exit=-13 a0=1abf2a8 a1=c1 a2=1a0 a3=3836343534353532 items=0 ppid=2517 pid=6327 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts8 ses=2 comm="semanage" exe="/usr/bin/python" subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-25.fc12,catchall,semanage,semanage_t,abrt_var_cache_t,dir,write audit2allow suggests: #============= semanage_t ============== allow semanage_t abrt_var_cache_t:dir write;
Why is abrt causing random applications to write to this directory? Do I need to allow every app on the system to write to a directory?
Jim what version of policycoreutils are you running? # /usr/sbin/semanage fcontext -t tmp_t '/t(/.*)?' /usr/sbin/semanage: Invalid command: semanage fcontext -t tmp_t /t(/.*)? # rpm -q policycoreutils policycoreutils-2.0.74-5.fc12.x86_64
Hi Dan, $ rpm -q policycoreutils policycoreutils-2.0.74-4.fc12.x86_64 which seems to be latest from my mirror's perspective. I do see newer in koji : policycoreutils-2.0.74-8.fc12 should I install that?
As you noticed in http://bugzilla.redhat.com/528731, this is not a bug, but rather the fact that I omitted the -a option. With -a it works fine: semanage fcontext -a -t tmp_t '/t(/.*)?'
If a python app throws an unhandled exception the abrt python-hook kicks in and tries to write the dump into /var/cache/abrt. Jirka
But why is it triggering the application to output there? Seems to be some kernel cleverness. Obviously this is not the semanage command writing to this cache?
This avc requires allow semanage_t abrt_var_cache_t:dir write; And I am sure if I allow this I will end up with allow semanage_t abrt_var_cache_t:file create_file_perms; But since any domain can crash, I need to allow allow domain abrt_var_cache_t:file create_file_perms; Meaning every process in the system will be allowed to write to directories labeld abrt_var_cache_t. Since I believe this is actually the abrt process writing to this directory, the kernel is getting it wrong.
No, it is not abrtd process. Crashing python script writes the data there. Whether it is wrong to do so or not is a design question...
Someone is redirecting the output from my crashing application to write to this directory. There is no code in semanage to write to this file/directory. So Why do I need to change every process to have the write to write to this directory. It is either abrt or kernel that need the permissions, and I should not see the AVC talking about my app writing there. I can not write secure policy if the kernel causes redirects of output and then claims that my process tried to write to a random directory.
stop blaming the kernel, it's python doing magic behind the scenes, not the kernel :-P
Look into /usr/lib/python2.6/site-packages/abrt_exception_handler.py this is the code which writes in that directory. It is executed by python. If you think it's a worng thing to do, well, I agree with you...
Ok I would prefer the tools to communicate with the abrt tool and then have abrt write the data to a random location. How are you trapping this when segfaults happen?
FYI, I provoked this by installing postfix, configuring main.cf per http://fedorasolved.org/server-solutions/postfix-mail-server, and trying to send the test mail: root@vm$ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 vm.meyering.net ESMTP Postfix EHLO meyering.net 250-vm.meyering.net 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN MAIL FROM: <user> 250 2.1.0 Ok My hitting return after typing the "MAIL FROM:..." line above is what provoked this AVC.
BTW, this is with abrt-0.0.10-1.fc12.x86_64 on an up to date F12-beta system (installed from scratch as F12-alpha).
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 532572 has been marked as a duplicate of this bug. ***
Uncaught Python exceptions are now sent to ABRT daemon via socket. Fixed in upstream git. SELinux policy has been updated by Mirek Grepl.
abrt-1.1.13-1.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/abrt-1.1.13-1.fc14
abrt-1.1.13-1.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/abrt-1.1.13-1.fc13
abrt-1.1.13-1.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update abrt'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/abrt-1.1.13-1.fc14
abrt-1.1.13-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/abrt-1.1.13-1.fc12
abrt-1.1.13-1.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
abrt-1.1.13-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/abrt-1.1.13-2.fc14
abrt-1.1.13-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
abrt-1.1.13-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.