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