SELinux error with yum --installroot

[Bob Kashani]

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

-- 
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome