Summary: SELinux prevented yum from writing updates-debuginfo. Detailed Description: SELinux prevented yum from writing updates-debuginfo. If updates-debuginfo is a core file, you may want to allow this. If updates-debuginfo is not a core file, this could signal an intrusion attempt. Allowing Access: Changing the "allow_daemons_dump_core" boolean to true will allow this access: "setsebool -P allow_daemons_dump_core=1." Fix Command: setsebool -P allow_daemons_dump_core=1 Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:root_t:s0 Target Objects updates-debuginfo [ dir ] Source yum Source Path /usr/bin/python Port <Unknown> Host (removed) Source RPM Packages python-2.7-7.fc14 Target RPM Packages Policy RPM selinux-policy-3.8.8-10.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name allow_daemons_dump_core Host Name (removed) Platform Linux (removed) 2.6.35-0.57.rc6.git1.fc14.x86_64 #1 SMP Mon Jul 26 22:43:02 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Wed 11 Aug 2010 09:08:33 PM CEST Last Seen Wed 11 Aug 2010 09:08:33 PM CEST Local ID 9b926f41-4b45-45f7-a683-173a515df462 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1281553713.29:218): avc: denied { create } for pid=2168 comm="yum" name="updates-debuginfo" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1281553713.29:218): arch=c000003e syscall=83 success=no exit=-13 a0=1a334b0 a1=1ed a2=7f102378fdc0 a3=7fffe5025f00 items=0 ppid=2167 pid=2168 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null) Hash String generated from allow_daemons_dump_core,yum,abrt_t,root_t,dir,create audit2allow suggests: #============= abrt_t ============== allow abrt_t root_t:dir create;
setsebool -P allow_daemons_dump_core=1 does not correct the problem. Putting selinux in permissive mode echo 0 >/selinux/enforce did not help. After executing both of the above, security alert read: Summary: SELinux prevented yum from writing updates-debuginfo. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux prevented yum from writing updates-debuginfo. If updates-debuginfo is a core file, you may want to allow this. If updates-debuginfo is not a core file, this could signal an intrusion attempt. Allowing Access: Changing the "allow_daemons_dump_core" boolean to true will allow this access: "setsebool -P allow_daemons_dump_core=1." Fix Command: setsebool -P allow_daemons_dump_core=1 Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:root_t:s0 Target Objects updates-debuginfo [ dir ] Source yum Source Path /usr/bin/python Port <Unknown> Host (removed) Source RPM Packages python-2.7-7.fc14 Target RPM Packages Policy RPM selinux-policy-3.8.8-10.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name allow_daemons_dump_core Host Name (removed) Platform Linux fedora14dw32 2.6.35-3.fc14.i686.PAE #1 SMP Fri Aug 6 19:41:17 UTC 2010 i686 i686 Alert Count 5 First Seen Wed 11 Aug 2010 03:08:15 AM EDT Last Seen Wed 11 Aug 2010 05:03:13 PM EDT Local ID d7e527a3-bd96-42de-9004-48812e9e0b65 Line Numbers Raw Audit Messages node=fedora14dw32 type=AVC msg=audit(1281560593.641:520): avc: denied { create } for pid=31217 comm="yum" name="updates-debuginfo" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir node=fedora14dw32 type=SYSCALL msg=audit(1281560593.641:520): arch=40000003 syscall=39 success=yes exit=0 a0=92a07b0 a1=1ed a2=47bf12c a3=8cd1050 items=0 ppid=31216 pid=31217 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)
This kind of looks like your system is mislabeled. The only directory on the machine that should be labeled root_t is /. touch /.autorelabel; reboot Should fix. Reopen if it does not.
I saw this in a fresh F14 Alpha RC4 installation from DVD - sealert crashed and abrt needed debuginfo. Since this installation was real fresh (5 minutes old and only used to see what messages sealert has so far). So either something with the policy is not right or something's going terribly wrong during the installation. Unfortunately the system I saw this on is out of reach until Monday so I wasn't able to try relabeling everything yet.
Ok if you can recreate reopen.
Reopening. I can confirm this problem on freshly installed F14 Alpha RC4 (DVD, x86_64). It probably popped up after running "debuginfo-install".
(In reply to comment #5) > Reopening. I can confirm this problem on freshly installed F14 Alpha RC4 (DVD, > x86_64). It probably popped up after running "debuginfo-install". Same here, but I couldn't reproduce it after a yum update so far.
If the labels do not get put down correctly during install, then it is probably an anaconda or rpm bug.
What file here is mislabeled? Keep in mind the only files anaconda modifies labels on are the ones it writes out itself. Everything else is handled by rpm. And if there is something going wrong with installation, we need the usual anaconda log files to be able to investigate.
I just did a fresh re-install of F14 alpha RC4. After enabling eth0 through the NM app it crashed and I was offered to log the crash. After installing the suggested debuginfo NetworkManager-gnome and doing a refresh to get a proper traceback the selinux AVC message appears: [root@f14alpha-rc4 log]# sealert -l d6086edd-9120-43a1-bf9e-23a1a32980c2 Summary: SELinux prevented yum from writing updates-debuginfo. Detailed Description: SELinux prevented yum from writing updates-debuginfo. If updates-debuginfo is a core file, you may want to allow this. If updates-debuginfo is not a core file, this could signal an intrusion attempt. Allowing Access: Changing the "allow_daemons_dump_core" boolean to true will allow this access: "setsebool -P allow_daemons_dump_core=1." Fix Command: setsebool -P allow_daemons_dump_core=1 Additional Information: Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023 Target Context system_u:object_r:root_t:s0 Target Objects updates-debuginfo [ dir ] Source yum Source Path /usr/bin/python Port <Unknown> Host f14alpha-rc4.slim Source RPM Packages python-2.7-7.fc14 Target RPM Packages Policy RPM selinux-policy-3.8.8-10.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name allow_daemons_dump_core Host Name f14alpha-rc4.slim Platform Linux f14alpha-rc4.slim 2.6.35-0.57.rc6.git1.fc14.x86_64 #1 SMP Mon Jul 26 22:43:02 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Tue Aug 17 19:58:35 2010 Last Seen Tue Aug 17 19:58:35 2010 Local ID d6086edd-9120-43a1-bf9e-23a1a32980c2 Line Numbers Raw Audit Messages node=f14alpha-rc4.slim type=AVC msg=audit(1282067915.732:394): avc: denied { create } for pid=2214 comm="yum" name="updates-debuginfo" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir node=f14alpha-rc4.slim type=SYSCALL msg=audit(1282067915.732:394): arch=c000003e syscall=83 success=no exit=-13 a0=1d1ba00 a1=1ed a2=7f4f8a02fdc0 a3=7fff35049a40 items=0 ppid=2213 pid=2214 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0-s0:c0.c1023 key=(null)
Dan - so what files are being complained about here?
I just did a quick test on an install here. nm-applet didn't crash, which made this a little difficult. I then ran restorecon -Rnvv / to see what it thought had incorrect labels. Aside from some crud in /dev and /tmp that didn't look important, there were also a couple things in /var/cache/yum that had a context of system_u:object_r:root_t:s0. And anaconda is involved when those directories get created. Could you try running restorecon just on the contents of /var/cache/yum and seeing if you are able to reproduce this problem?
That is the problem directory. node=f14alpha-rc4.slim type=AVC msg=audit(1282067915.732:394): avc: denied { create } for pid=2214 comm="yum" name="updates-debuginfo" scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir This AVC shows yum trying to create a directory updates-debuginfo labeled root_t. Which indicates the directory was being created within a directory labeled root_t. The only directory on the system that should be labeled root_t is /. Can you add /var/cache/yum to the magic list of directories that anaconda fixes.
OK I did another fresh install and check the selinux context of /var/cache/yum before and after doing the restorecon. The results are as follows: drwxr-xr-x. root root system_u:object_r:rpm_var_cache_t:s0 . drwxr-xr-x. root root system_u:object_r:var_t:s0 .. drwxr-xr-x. root root system_u:object_r:root_t:s0 x86_64 [root@f14alpharc4 ~]# restorecon /var/cache/yum/ [root@f14alpharc4 ~]# ls -alZ /var/cache/yum/ drwxr-xr-x. root root system_u:object_r:rpm_var_cache_t:s0 . drwxr-xr-x. root root system_u:object_r:var_t:s0 .. drwxr-xr-x. root root system_u:object_r:root_t:s0 x86_64 [root@f14alpharc4 ~]# ls -alZ /var/cache/yum/x86_64/ drwxr-xr-x. root root system_u:object_r:root_t:s0 . drwxr-xr-x. root root system_u:object_r:rpm_var_cache_t:s0 .. drwxr-xr-x. root root system_u:object_r:root_t:s0 14-Alpha [root@f14alpharc4 ~]# ls -alZ /var/cache/yum/x86_64/14-Alpha/ drwxr-xr-x. root root system_u:object_r:root_t:s0 . drwxr-xr-x. root root system_u:object_r:root_t:s0 .. I forgot the -R with restorecon so I tried again: [root@f14alpharc4 ~]# restorecon -R /var/cache/yum/ [root@f14alpharc4 ~]# ll -Z /var/cache/yum/ drwxr-xr-x. root root system_u:object_r:rpm_var_cache_t:s0 x86_64 [root@f14alpharc4 ~]# ll -Z /var/cache/yum/x86_64/ drwxr-xr-x. root root system_u:object_r:rpm_var_cache_t:s0 14-Alpha So this is the correct context. To check I purposely triggered bug #622006 / #603566 and installed debuginfo NetworkManager-gnome and reported the bug succesfully without any AVC.
This bug has been in modified since 2010-08-19 and several people, including me continue to hit it. Will it be addressed in Fedora 14?
Please include useful data, like which version of anaconda you were using.
Summary: SELinux prevented yum from writing fedora-debuginfo. Detailed Description: SELinux prevented yum from writing fedora-debuginfo. If fedora-debuginfo is a core file, you may want to allow this. If fedora-debuginfo is not a core file, this could signal an intrusion attempt. Allowing Access: Changing the "allow_daemons_dump_core" boolean to true will allow this access: "setsebool -P allow_daemons_dump_core=1." Fix Command: setsebool -P allow_daemons_dump_core=1 Additional Information: Source Context system_u:system_r:abrt_t:s0 Target Context system_u:object_r:root_t:s0 Target Objects fedora-debuginfo [ dir ] Source yum Source Path /usr/bin/python Port <Unknown> Host kvm Source RPM Packages python-2.7-7.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.3-4.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name allow_daemons_dump_core Host Name kvm Platform Linux kvm 2.6.35.4-12.fc14.x86_64 #1 SMP Fri Aug 27 07:45:05 UTC 2010 x86_64 x86_64 Alert Count 6 First Seen Thu 02 Sep 2010 06:45:43 PM PDT Last Seen Mon 13 Sep 2010 10:36:50 AM PDT Local ID fde27841-443b-4c29-ab2f-cd9ea684dc93 Line Numbers Raw Audit Messages node=kvm type=AVC msg=audit(1284399410.986:50): avc: denied { create } for pid=25120 comm="yum" name="fedora-debuginfo" scontext=system_u:system_r:abrt_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir node=kvm type=SYSCALL msg=audit(1284399410.986:50): arch=c000003e syscall=83 success=no exit=-13 a0=24b7eb0 a1=1ed a2=3f9a1cbdc0 a3=34312f34365f3638 items=0 ppid=25119 pid=25120 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="yum" exe="/usr/bin/python" subj=system_u:system_r:abrt_t:s0 key=(null)
The anaconda that shipped with the Fedora 14 Alpha.
That was anaconda-14.15-2, and you'll notice the Fixed In Version: field above says anaconda-14.17-1, which is later. So it was not fixed in the alpha but is fixed post-alpha for the beta.
anaconda 14.17.1 is on the F14-Beta-TC1 net installer disc: http://serverbeach1.fedoraproject.org/pub/alt/stage/14-Beta.TC1/ F14-Beta-TC1 announced was 2010-09-09 here: http://comments.gmane.org/gmane.linux.redhat.fedora.test.announce/128 Install testing status is here: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Sorry I am a newbie and just didn't understand how I can correct this posted problem on my laptop Asus z71. I have got this problem too, since I installed and configured, under Gnome interface, the package named Smart Package Manager V.1.3 program to get rpm packages from the follow repository: rpm-db next are not checked------- http://download1.rpmfusion.org/free/fedora/releases/14/Everything/i586/os/ http://download1.rpmfusion.org/free/fedora/releases/14/Everything/source/SRPMS/ http://download1.rpmfusion.org/free/fedora/releases/14/Everything/i386/os/ Can somebody help me? I thanks all for the collaboration anticipately. Cheers, Paolo Corsi