Bug 243658 - Many ldconfig AVC denials on update
Many ldconfig AVC denials on update
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-06-11 06:18 EDT by Ingemar Nilsson
Modified: 2008-01-30 14:19 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-30 14:19:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
My audit.log (1.02 MB, text/plain)
2007-08-17 07:58 EDT, Ingemar Nilsson
no flags Details

  None (edit)
Description Ingemar Nilsson 2007-06-11 06:18:26 EDT
Description of problem:

On latest F7 update (including the latest Gnome update), there were a lot of AVC
denials for ldconfig.

    SELinux is preventing /sbin/ldconfig (ldconfig_t) "search" to bin (bin_t).

Detailed Description
    SELinux denied access requested by /sbin/ldconfig. It is not expected that
    this access is required by /sbin/ldconfig 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
    Sometimes labeling problems can cause SELinux denials.  You could try to
    restore the default system file context for bin, restorecon -v bin If this
    does not work, there is currently no automatic way to allow this access.
    Instead,  you can generate a local policy module to allow this access - see
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
    SELinux protection altogether. Disabling SELinux protection is not
    recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
    against this package.

Additional Information        

Source Context                user_u:system_r:ldconfig_t
Target Context                system_u:object_r:bin_t
Target Objects                bin [ dir ]
Affected RPM Packages         glibc-2.6-3 [application]filesystem-2.4.6-1.fc7
Policy RPM                    selinux-policy-2.6.4-13.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall_file
Host Name                     tyrannosaurus
Platform                      Linux tyrannosaurus 2.6.21-1.3194.fc7 #1 SMP Wed
                              May 23 22:35:01 EDT 2007 i686 i686
Alert Count                   89
First Seen                    Fri 08 Jun 2007 07:18:49 PM CEST
Last Seen                     Mon 11 Jun 2007 11:58:21 AM CEST
Local ID                      0a30cc40-f5c0-4466-8bf4-d0028422891f
Line Numbers                  

Raw Audit Messages            

avc: denied { search } for comm="ldconfig" dev=sda8 egid=0 euid=0
exe="/sbin/ldconfig" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="bin" pid=4397
scontext=user_u:system_r:ldconfig_t:s0 sgid=0 subj=user_u:system_r:ldconfig_t:s0
suid=0 tclass=dir tcontext=system_u:object_r:bin_t:s0 tty=(none) uid=0
Comment 1 Daniel Walsh 2007-06-11 10:31:29 EDT
This looks like some app placed a shared library under a bin directory?
Comment 2 Daniel Walsh 2007-08-14 07:54:26 EDT
Since I did not get a response on this, I think it is either a labeling problem
or some other bad application.  Closing as not a bug for now.
Comment 3 Ingemar Nilsson 2007-08-17 05:50:45 EDT
How should I know what the answer to your question is? I see these AVC errors at
almost every "yum update" (last time today), but I've gotten so used to them
that I hardly notice them any more.

Since the error message does not contain any file reference except the program
(ldconfig), how could I know where to start looking? I understand that ldconfig
did *something* that the SELinux policy didn't allow, but what?
Comment 4 Daniel Walsh 2007-08-17 06:19:14 EDT
Ok so please attach you audit.log to this bugzilla.  

ausearch -m avc | less

Then look for ldconfig might give you more information.
Comment 5 Ingemar Nilsson 2007-08-17 07:58:20 EDT
Created attachment 161727 [details]
My audit.log

Well, here is my audit.log. I briefly tried to read it, but it isn't very
intelligible to me.
Comment 6 Daniel Walsh 2007-08-20 17:14:22 EDT
Ok, I will add policy to allow this, but I still have no idea what ldconfig is
looking for in bin_t directories.

Fixed in selinux-policy-2.6.4-39
Comment 7 Ingemar Nilsson 2007-08-22 05:44:50 EDT
Okay, I get it. I ran an strace on ldconfig, and it turns out that it gets three
"Permission denied", all associated with libraries in my IBM Tivoli Storage
Manager client that I use for backups to our tape robot. The client has its
libraries (and everything else, binaries, config files, you name it) in
/opt/tivoli/tsm/client/ba/bin which is a bin_t directory. The reason ldconfig
tries to access them is that the rpm that I used to install them placed symbolic
links to three libraries in /usr/lib.

Sorry for bothering you. I certainly understand that you cannot support
proprietary software.
Comment 8 Ingemar Nilsson 2007-08-22 05:48:13 EDT
One could wish though that SELinux could give information about what files or
directories it could not permit access to. That could have simplifies this
process a lot (if I had known immediately that the messages were related to my
Tivoli client, I would not have filed this report at all). Could such a feature
be possible?
Comment 9 Daniel Walsh 2007-08-22 08:46:20 EDT
This is actually a bug in the kernel/audit system that is preventing the
gathering of this information.  It is fixed or being fixed in the upstream kernels.

BTW, We do strive to fix problems in Proprietary code as well.  
Comment 10 Daniel Walsh 2008-01-30 14:19:17 EST
Bulk closing all bugs in Fedora updates in the modified state.  If you bug is
not fixed, please reopen.

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