SELinux error with yum --installroot

[Daniel J Walsh]

Bob Kashani wrote:

>On Tue, 2005-01-04 at 10:18 -0500, Stephen Smalley wrote:
>  
>
>>On Tue, 2005-01-04 at 02:14, Bob Kashani wrote:
>>    
>>
>>>But here is the log message that I get when ldconfig fails in /home (as
>>>requested by Stephen).
>>>
>>>Jan  3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc:  denied
>>>{ search } for  pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1
>>>ino=855792 scontext=root:system_r:ldconfig_t
>>>tcontext=user_u:object_r:file_t tclass=dir
>>>Jan  3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc:  denied
>>>{ search } for  pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1
>>>ino=855792 scontext=root:system_r:ldconfig_t
>>>tcontext=user_u:object_r:file_t tclass=dir
>>>      
>>>
>>First, I'd suggest relabeling /home, as there shouldn't be any file_t
>>files there.  restorecon -R /home.  Was /home inherited from a prior
>>install, or did you run a non-SELinux kernel while creating files there?
>>    
>>
>
>Well, /home/gnome (my test user account) is actually a symbolic link
>to /mnt/hdb1/home/gnome (this way I can log into the same account from
>rawhide and FC3 without having to copy files around). /home is on hda3
>and /home/gnome is on hdb1. hdb1 has rawhide installed on it and I had
>turned off selinux a long time ago since it was giving me problems. But
>all of the files in /home/gnome were created under FC3 w/ selinux. I
>booted into rawhide (hdb1) and enabled selinux and ran 'restorecon -
>R /'. Now when I'm in FC3 file_t is gone. :)
>
>  
>
>>Second, ldconfig is normally restricted in the set of types it can
>>access; see the "SELinux and third party installers" thread.  This can
>>be changed in the policy if necesssary, but understand that there are
>>implications.
>>    
>>
>
>I read the thread and I seem to understand the technical reason behind
>why ldconfig is restricted in the way that it is (the security side of
>the issue). But is seems a little harsh from a usability point of view
>since for example, you can no longer run ldconfig in a chroot in your
>home dir. I like fine grained security but isn't the whole idea behind
>policy-targeted to enable security without restricting usability too
>much? I would understand not allowing ldconfig to execute in /home with
>policy-strict but shouldn't policy-targeted allow you to do this
>regardless of the potential security issues? Do the security concerns in
>this case outweigh the usability issues?
>
>Bob
>
>  
>
What AVC messages are you seeing.  We can and probably should loosen up 
ldconfig policy for targeted.

Dan