Bug 623434 - SELinux prevented yum from writing updates-debuginfo.
SELinux prevented yum from writing updates-debuginfo.
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
14
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Chris Lumens
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:f3a0d620702...
: Reopened
Depends On:
Blocks: F14Target
  Show dependency treegraph
 
Reported: 2010-08-11 15:14 EDT by Jurgen Kramer
Modified: 2011-12-22 14:24 EST (History)
28 users (show)

See Also:
Fixed In Version: anaconda-14.17-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-22 14:24:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jurgen Kramer 2010-08-11 15:14:08 EDT
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;
Comment 1 GoinEasy9 2010-08-11 17:08:50 EDT
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)
Comment 2 Daniel Walsh 2010-08-13 12:15:50 EDT
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.
Comment 3 Sandro Mathys 2010-08-13 14:58:39 EDT
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.
Comment 4 Daniel Walsh 2010-08-13 15:10:53 EDT
Ok if you can recreate reopen.
Comment 5 Kamil Páral 2010-08-16 10:49:57 EDT
Reopening. I can confirm this problem on freshly installed F14 Alpha RC4 (DVD, x86_64). It probably popped up after running "debuginfo-install".
Comment 6 Sandro Mathys 2010-08-16 10:59:10 EDT
(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.
Comment 7 Daniel Walsh 2010-08-17 06:59:58 EDT
If the labels do not get put down correctly during install, then it is probably an anaconda or rpm bug.
Comment 8 Chris Lumens 2010-08-17 09:06:45 EDT
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.
Comment 9 Jurgen Kramer 2010-08-17 14:03:18 EDT
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)
Comment 10 Chris Lumens 2010-08-17 14:15:59 EDT
Dan - so what files are being complained about here?
Comment 11 Chris Lumens 2010-08-17 15:47:25 EDT
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?
Comment 12 Daniel Walsh 2010-08-18 07:50:56 EDT
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.
Comment 13 Jurgen Kramer 2010-08-18 14:35:32 EDT
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.
Comment 14 John Poelstra 2010-09-13 13:39:35 EDT
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?
Comment 15 Chris Lumens 2010-09-13 15:17:04 EDT
Please include useful data, like which version of anaconda you were using.
Comment 16 John Poelstra 2010-09-13 16:23:29 EDT
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)
Comment 17 John Poelstra 2010-09-13 16:27:23 EDT
The anaconda that shipped with the Fedora 14 Alpha.
Comment 18 Chris Lumens 2010-09-13 16:33:43 EDT
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.
Comment 19 Steve Tyler 2010-09-13 17:02:08 EDT
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
Comment 20 Corsi P. 2010-10-22 04:39:35 EDT
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

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