Description of problem: On latest F7 update (including the latest Gnome update), there were a lot of AVC denials for ldconfig. Summary 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 [target] 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
This looks like some app placed a shared library under a bin directory?
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.
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?
Ok so please attach you audit.log to this bugzilla. ausearch -m avc | less Then look for ldconfig might give you more information.
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.
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
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.
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?
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.
Bulk closing all bugs in Fedora updates in the modified state. If you bug is not fixed, please reopen.