Bug 546152 (abrt_etc) - SELinux is preventing /usr/sbin/abrtd (deleted) "write" access on /etc/abrt.
Summary: SELinux is preventing /usr/sbin/abrtd (deleted) "write" access on /etc/abrt.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: abrt_etc
Product: Fedora
Classification: Fedora
Component: abrt
Version: 12
Hardware: i386
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jiri Moskovcak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: setroubleshoot_trace_hash:77cd1484f8d...
: 550523 550860 552118 557565 557590 557606 559319 560484 560898 562482 568988 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-12-10 08:11 UTC by edo
Modified: 2018-04-11 12:16 UTC (History)
57 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-02-17 19:28:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
yum.log (excerpt) (24.74 KB, text/plain)
2009-12-10 16:00 UTC, Patrick
no flags Details

Description edo 2009-12-10 08:11:24 UTC
Summary:

SELinux is preventing /usr/sbin/abrtd (deleted) "write" access on /etc/abrt.

Detailed Description:

[abrtd has a permissive type (abrt_t). This access was not denied.]

SELinux denied access requested by abrtd. It is not expected that this access is
required by abrtd 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:abrt_etc_t:s0
Target Objects                /etc/abrt [ dir ]
Source                        abrtd
Source Path                   /usr/sbin/abrtd (deleted)
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           abrt-1.0.1-1.fc12
Policy RPM                    selinux-policy-3.6.32-56.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     (removed)
Platform                      Linux (removed)
                              2.6.31.6-162.fc12.i686.PAE #1 SMP Fri Dec 4
                              00:43:59 EST 2009 i686 i686
Alert Count                   3
First Seen                    Št 10. december 2009, 09:04:53 CET
Last Seen                     Št 10. december 2009, 09:04:53 CET
Local ID                      dc0bab80-c95c-45bf-9514-27fde24038bc
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1260432293.557:36): avc:  denied  { write } for  pid=1186 comm="abrtd" name="abrt" dev=dm-0 ino=123005 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir

node=(removed) type=AVC msg=audit(1260432293.557:36): avc:  denied  { add_name } for  pid=1186 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir

node=(removed) type=AVC msg=audit(1260432293.557:36): avc:  denied  { create } for  pid=1186 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=file

node=(removed) type=SYSCALL msg=audit(1260432293.557:36): arch=40000003 syscall=5 success=yes exit=9 a0=3f10c9 a1=8241 a2=1b6 a3=b9d649 items=0 ppid=1 pid=1186 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe=2F7573722F7362696E2F6162727464202864656C6574656429 subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  selinux-policy-3.6.32-56.fc12,catchall,abrtd,abrt_t,abrt_etc_t,dir,write
audit2allow suggests:

#============= abrt_t ==============
allow abrt_t abrt_etc_t:dir { write add_name };
allow abrt_t abrt_etc_t:file create;

Comment 1 Daniel Walsh 2009-12-10 15:40:42 UTC
Abrt should not be rewriting its own config.

Comment 2 Jiri Moskovcak 2009-12-10 16:00:02 UTC
New version fixes this, but it can happen when user updates from the old version and abrtd is restarted.

Jirka

Comment 3 Patrick 2009-12-10 16:00:42 UTC
Created attachment 377498 [details]
yum.log (excerpt)

The problem occured during a 'yum update'.

Comment 4 Jiri Moskovcak 2009-12-11 11:07:44 UTC
(In reply to comment #3)
> Created an attachment (id=377498) [details]
> yum.log (excerpt)
> 
> The problem occured during a 'yum update'.  

Yes that's the case. When you're updating abrt it restarts abrtd and that's what causing this. It's fixed and won't happen with the new version.

Comment 5 Daniel Walsh 2009-12-30 00:11:25 UTC
*** Bug 550860 has been marked as a duplicate of this bug. ***

Comment 6 Miroslav Grepl 2010-01-04 13:04:48 UTC
*** Bug 552118 has been marked as a duplicate of this bug. ***

Comment 7 Daniel Walsh 2010-01-15 13:46:09 UTC
*** Bug 550523 has been marked as a duplicate of this bug. ***

Comment 8 Daniel Walsh 2010-01-21 21:50:59 UTC
*** Bug 557565 has been marked as a duplicate of this bug. ***

Comment 9 Daniel Walsh 2010-01-21 22:24:57 UTC
*** Bug 557590 has been marked as a duplicate of this bug. ***

Comment 10 Miroslav Grepl 2010-01-22 10:41:50 UTC
*** Bug 557606 has been marked as a duplicate of this bug. ***

Comment 11 Daniel Walsh 2010-01-27 18:41:31 UTC
*** Bug 559319 has been marked as a duplicate of this bug. ***

Comment 12 Miroslav Grepl 2010-02-01 15:42:16 UTC
*** Bug 560484 has been marked as a duplicate of this bug. ***

Comment 13 Miroslav Grepl 2010-02-02 12:09:47 UTC
*** Bug 560898 has been marked as a duplicate of this bug. ***

Comment 14 Miroslav Grepl 2010-02-08 08:55:19 UTC
*** Bug 562482 has been marked as a duplicate of this bug. ***

Comment 15 Ulrich Hobelmann 2010-02-08 16:18:25 UTC
Jiri, you say it won't happen with the new version, but which version is that?  I have an up-to-date Fedora 12 and I get this problem every time I start the computer and log in.

This bug still "NEW", so it isn't fixed, is it?  Just wondering what the current status is.

Comment 16 Rajmahendra 2010-02-10 03:58:34 UTC
hi sorry. i may be submitting same bug again again. 

i am also getting this same bug again and again when i login.

Comment 17 Jiri Moskovcak 2010-02-10 09:32:44 UTC
(In reply to comment #16)
> hi sorry. i may be submitting same bug again again. 
> 
> i am also getting this same bug again and again when i login.

This is fixed a long time ago, if you have the latest ABRT (1.0.6) it shouldn't happen, maybe it's just the sealert reporting some old AVC again and again..

J.

Comment 18 Rajmahendra 2010-02-10 12:39:48 UTC
ABRT (1.0.6)! 

How can i upgrade it ? any way to check what version i am using ?

Comment 19 Jiri Moskovcak 2010-02-10 12:53:22 UTC
(In reply to comment #18)
> ABRT (1.0.6)! 
> 
> How can i upgrade it ? 

$ yum update abrt

> any way to check what version i am using ?    

$ rpm -q abrt

Comment 20 Rajmahendra 2010-02-10 13:08:47 UTC
Thank you Jiri.

I will update the abrt and update you soon.

Comment 21 Rajmahendra 2010-02-10 18:08:50 UTC
hi 

i used following command... 

$ rpm -q abrt    

it displays..  abrt-1.0.6-1.fc12.i686

i tried 

$ yum update abrt

but "no packages marked for update"!!!

Comment 22 Rajmahendra 2010-02-10 18:12:51 UTC
i have a doubt...

your bugtool says Platform:	i386 Linux

i feel my system is looks 386... but KDE once i install it said 686!!! any issue in this ?

when i installed i had only GNOME and later i installed using yum install kde-desktop but it downloaded 686!!!!

Will this create issue ?

Comment 23 Daniel Walsh 2010-02-10 19:32:55 UTC
No i686 is binaries compiled for the i386 platform.

Comment 24 Damien Spaulding 2010-02-11 03:01:23 UTC
I am running...

[root@BLACKHEARTED ~]# rpm -q abrt
abrt-1.0.6-1.fc12.i686

And I still get this error on start up.

Comment 25 Ulrich Hobelmann 2010-02-11 05:44:50 UTC
I got the message (and red ABRT bulb) on every startup.  Somewhere it said that ABRT was not even running, though (I didn't disable it, it just didn't start for some reason.)

A su -c '/etc/init.d/abrtd restart' solved the problem.  (Still got an SELinux warning on the next boot, but after clearing all warnings, the system now gets a clean start.)

Comment 26 Rajmahendra 2010-02-11 12:54:32 UTC
@u.hobelmann
I will try this today. 

>>(Still got an SELinux warning on the next boot, but after clearing all warnings, the system now gets a clean start.)

How to clear the warnings ? Check igore alert ?

You mean if i give su -c '/etc/init.d/abrtd restart'  each start it automatically starts ?

Comment 27 Daniel Walsh 2010-02-11 14:00:15 UTC
There is a bug in setroubleshoot that is reporting already seen alerts as new, when you login.

Fixed in setroubleshoot-2.2.63-1.fc12       
yum update setroubleshoot\* --enablerepo=updates-testing

Comment 28 hal 2010-02-13 18:01:59 UTC
Three's still something not quite right.  After applying all available fc12 patches this morning, I'm still getting a black box with a security warning after rebooting, but the text is empty.  The selinux window shows "no bugs" when I open it after that, and once it's closed everything seems ok.  But it still happens again on the next boot.  This behavior has been around for a week or two now.

Comment 29 Daniel Walsh 2010-02-14 14:43:23 UTC
Could you remove the ~/.setroubleshoot file from your homedir and see if this fixes the problem

Comment 30 hal 2010-02-14 16:54:59 UTC
That did fix the problem, but in a somewhat roundabout way.

Removing ~/.setroubleshoot didn't solve it.  On the next reboot the black warning box still appeared, but with no specific message, just as before.  The selinux warning star in the menu bar also appeared after the warning box, only this time the original message about the abrt problem was back when I clicked it, unlike before.  (The message was roughly "abrt triggered a security violation on Jan. 10 and this had happened 3 times since".  Sorry, I forgot to write the full thing down.)

Rebooting after closing the selinux box produced the same behavior.  This time I clicked "dismiss" after viewing the selinux warning.  After that, the next reboot went without triggering either the warning or a selinux report.

So it seems to be fixed, but it took the combination of both deleting ~/.setroubleshoot and answering "dismiss" after looking at the selinux details to make it happen.  Just deleting the file wasn't enough.

Comment 31 Daniel Walsh 2010-02-15 12:57:46 UTC
What version of setroubleshoot do you now have installed

rpm -q setroubleshoot

Comment 32 hal 2010-02-15 16:29:07 UTC
$ rpm -q setroubleshoot
setroubleshoot-2.2.63-2.fc12.i686

Comment 33 Daniel Walsh 2010-02-16 18:02:29 UTC
When you say the "black box"  Do you think this is an abrt black box or an SELinux/SEtroubleshoot box?  Does the Setroubleshoot "star" appear?

Comment 34 hal 2010-02-17 01:58:32 UTC
I'm pretty sure that the "black box" was something displayed by selinux/setroubleshoot.  It appeared just below the menu bar at the top-right of the screen and didn't look like a conventional alert box.  Black background with white lettering, and a small circle that started out black and swept out a white circle like a second hand going around a clock.  After that was done and disappeared, the "star" appeared in the menu bar.

Comment 35 Daniel Walsh 2010-02-17 14:26:55 UTC
Did the Yellow SELinux Star appear, if not, then it is not the SELinux tool putting it up.

Comment 36 Daniel Walsh 2010-02-17 14:27:28 UTC
You could look into ~/.xsession-errors to see if anything gets written there.

Comment 37 hal 2010-02-17 15:11:09 UTC
Yes, the star that appeared after the black box was the selinux star, and clicking that was what opened the selinux window with the message about abrt triggering a security violation on Jan. 10 and 3 times since then.

Here's the full contents of .xsession-errors, for whatever it may be worth:

$ cat .xsession-errors
GNOME_KEYRING_SOCKET=/tmp/keyring-FQ0lJT/socket
SSH_AUTH_SOCK=/tmp/keyring-FQ0lJT/socket.ssh
Failed to play sound: File or data not found
** Message: NumLock remembering disabled because hostname is set to "localhost"

(polkit-gnome-authentication-agent-1:1633): GLib-GObject-WARNING **: cannot regi
ster existing type `_PolkitError'

(polkit-gnome-authentication-agent-1:1633): GLib-CRITICAL **: g_once_init_leave:
 assertion `initialization_value != 0' failed
Initializing nautilus-gdu extension

Comment 38 Daniel Walsh 2010-02-17 16:03:39 UTC
Could you paste in the actuall message?

Comment 39 hal 2010-02-17 16:19:06 UTC
Not sure how I'd find it.  It no longer appears after the fiddling I did (see #30) to clear up the message and remove ~/.setroubleshoot.  Is it saved somewhere?

Comment 40 Daniel Walsh 2010-02-17 16:50:43 UTC
ausearch -m avc 

Will list it.

I thought you said the Star is still appearing, without a message. But when you click on the star you see the old data.

Comment 41 hal 2010-02-17 18:37:08 UTC
Won't be able to get to that machine until later to try listing the error.

But to avoid confusion, once I did get rid of .setroubleshoot and dismissed the selinux warning the messages disappeared.  Before I did any of that, I was getting the black warning box with no messages filled in for the placeholders, and clicking on the star gave me an empty selinux box.  After removing .setroubleshoot the first time, I was still seeing the black warning box followed by the selinux star, and clicking on the star produced the message again.  After yet another reboot and using "dismiss" to get rid of the selinux message instead of just closing the box, the whole thing went away and hasn't been back since.

Comment 42 Daniel Walsh 2010-02-17 19:28:34 UTC
Ok.  I will close this bug, and if anyone sees this issue again they can reopen.

Comment 43 nakieb 2010-02-18 12:07:47 UTC
SEtoubleshoot current release still shows this alert for it happened 27 days ago. Other alerts were removed after updating SEtroubleshoot and SELinuxPloicy

Comment 44 Daniel Walsh 2010-02-18 14:18:07 UTC
Other alerts are now allowed or dontaudited in policy.  setroubleshoot is only cleaning alert messages that would not happen again.  Since abrt is not allowed to write to /etc/abrt, setroubleshoot will not remove this AVC.  You are welcome to delete it your self.  abrt has been updated so this should not happen in the future.

Comment 45 Les Howell 2010-02-19 21:30:55 UTC
Les Howell here....
I just finished a complete reload and full update of my system to F12 last night.  I loaded my user files just now and logged in as my normal user.

This error came after all that.

I will see if it returns and then seek to either re-open this bug or start a new one.

Regards,
Les H

Comment 46 Les Howell 2010-02-19 21:52:22 UTC
deleted the last group of reports, rebooted and logged in again.  This bug is still present.  I'll try an auto relable to see if that relieves it.

After that, some other action will be required.

Comment 47 Daniel Walsh 2010-02-20 13:07:12 UTC
Les  Which problem are you saying is still there.  THe abrt message is still happening or setroublshoot is complaining about an old abrt message everytime you log-in?

Comment 48 Les Howell 2010-02-20 21:55:57 UTC
I deleted the reports, so it should not be complaining about the old reports.  I get the message each time I log in, so far.

I just finished the full update to the fresh F12 install.  I have not enabled the windows dual boot yet (I lost my notes, so I have to figure it out again with help from google).  The process was: 
  1. recover my user files via a recovery program (backup was hosed)
  2. install new drive, powersupply, and DVD writer (apparently destroyed by the surge that killed my backup and disk)
  3. Download F12 and make the disk.
  4. FUll install, and 460+updates
  5. find error message
  6. log it with bugzilla
  7. make new password for bugzilla
  8. add comments
  9. Delete the message(s) from the SELinux logs
  9. reboot and get the same error
 10. add that to bugzilla and add comments
 11. continue to get error message on successive reboots after deleting them each time.

That's where I am today.  Oh, yes, somewhere in there I looked for a solution and didn't find one.  Either I have not yet received the correct update, or the bug still exists somehow.  I even tried .autorelable last night to no success, and with more than 30G on this system that takes a while.  I still haven't reloaded all the applications I use, either.  This has been a tough week.  Three computers down, and this is my main one, and it is still not up to snuff for my work. RAZZBERRIES.

Regards,
Les H

Comment 49 Les Howell 2010-02-22 04:52:32 UTC
After all the latest updates last night, the errors seem to have vanished.  I no longer see them, and no new errors are showing up.  Whatever you have done, it worked...  Of course, you nice supporters may not have done anything, in which case I am baffled... But happy that the mysterious "abrt error" has taken what appears to be a permanent holiday.

Thank you for your support and kind ears.

REgards,
Les H

Comment 50 Daniel Walsh 2010-02-27 12:57:37 UTC
*** Bug 568988 has been marked as a duplicate of this bug. ***

Comment 51 Toshi 2010-03-13 21:17:43 UTC
Fresh install. updated PackageKit. Updated all updates listed in the Update
Manager. I recieved this error, and not to soon after received a network
manager error.   I am very new to linux and fedora and have very little
knowledge when it comes to understanding where to look for certain files.   I
would like to know how to fix this bug.

$ rpm -q abrt
abrt-1.0.8-2.fc12.i686


This is the version I am using according to the instructions I found online to
check the version. 

Please let me know what next steps I need to take.

Comment 52 Dennis 2010-03-15 01:50:21 UTC
I am getting this error now. Happens each time I login.

Just installed Fedora 12.
System is fully up to date.
SELinux is set to permissive.

Ran this command:
$rpm -q abrt
abrt-1.0.8-2.fc12.i686

Comment 53 Keith G. Robertson-Turner 2010-04-25 17:14:50 UTC
Confirmed here: This warning persists even after an update, deleting the existing log, and reboot.

ausearch -m avc

type=SYSCALL msg=audit(1272195294.301:17258): arch=40000003 syscall=5 success=yes exit=9 a0=3be0b9 a1=8241 a2=1b6 a3=3c14629 items=0 ppid=1 pid=1418 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe=2F7573722F7362696E2F6162727464202864656C6574656429 subj=system_u:system_r:abrt_t:s0 key=(null)
type=AVC msg=audit(1272195294.301:17258): avc:  denied  { create } for  pid=1418 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=file
type=AVC msg=audit(1272195294.301:17258): avc:  denied  { add_name } for  pid=1418 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir
type=AVC msg=audit(1272195294.301:17258): avc:  denied  { write } for  pid=1418 comm="abrtd" name="abrt" dev=dm-1 ino=23447 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir

abrt-1.0.9-1.fc12.i686
selinux-policy-targeted-3.6.32-110.fc12.noarch

Have not checked for test releases in rawhide or koji.

Comment 54 Keith G. Robertson-Turner 2010-04-25 17:20:48 UTC
+1 reopen this bug

Comment 55 Cameron Garnham 2010-05-04 00:27:13 UTC
After a fresh install of 12, I ran the command yum update, this error appears after update, and upon reboot.


Summary:

SELinux is preventing /usr/sbin/abrtd (deleted) "write" access on abrt.

Detailed Description:

[abrtd has a permissive type (abrt_t). This access was not denied.]

SELinux denied access requested by abrtd. It is not expected that this access is
required by abrtd 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://docs.fedoraproject.org/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:abrt_etc_t:s0
Target Objects                abrt [ dir ]
Source                        abrtd
Source Path                   /usr/sbin/abrtd (deleted)
Port                          <Unknown>
Host                          cameron-lap.garnham
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.32-110.fc12
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   catchall
Host Name                     cameron-lap.garnham
Platform                      Linux cameron-lap.garnham 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                    Tue 04 May 2010 01:16:26 AM EST
Last Seen                     Tue 04 May 2010 01:16:26 AM EST
Local ID                      6ccd241c-7424-4ad4-9b99-0eef626fc634
Line Numbers                  

Raw Audit Messages            

node=cameron-lap.garnham type=AVC msg=audit(1272899786.30:242): avc:  denied  { write } for  pid=1381 comm="abrtd" name="abrt" dev=dm-0 ino=272633 scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir

node=cameron-lap.garnham type=AVC msg=audit(1272899786.30:242): avc:  denied  { add_name } for  pid=1381 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=dir

node=cameron-lap.garnham type=AVC msg=audit(1272899786.30:242): avc:  denied  { create } for  pid=1381 comm="abrtd" name="pyhook.conf" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:abrt_etc_t:s0 tclass=file

node=cameron-lap.garnham type=SYSCALL msg=audit(1272899786.30:242): arch=c000003e syscall=2 success=yes exit=9 a0=7f365460c5f5 a1=241 a2=1b6 a3=0 items=0 ppid=1 pid=1381 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="abrtd" exe=2F7573722F7362696E2F6162727464202864656C6574656429 subj=system_u:system_r:abrt_t:s0 key=(null)


Note You need to log in before you can comment on or make changes to this bug.