Mike Hearn wrote:
On Tue, 04 Jan 2005 13:01:01 -0500, Colin Walters wrote:
Well, it's not beautiful. But we need some solution. Even if we got
changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent
tomorrow, all of their existing tarballs would be broken, forever.
Actually I just saw in CVS that Dan added the following permission:
allow ldconfig_t lib_t:file r_file_perms;
Would that fix this?
Yes
Jan 4 19:07:22 littlegreen kernel: audit(1104865642.095:0): avc: denied { read } for pid=25822 exe=/sbin /ldconfig name=libiculx.so.26.2 dev=hdd2
ino=2212143 scontext=root:system_r:ldconfig_t tcontext=root:object_
r:lib_t tclass=file
This is actually from doing an "apt-get install mono" on FC3 + apt + SELinux enabled so RPM was involved.
The result is that running mono fails:
[root@littlegreen tmp]# mono mono: error while loading shared libraries: libmono.so.0: cannot open shared object file: No such file or directory
So essentially in the targeted policy only the targeted daemons will be
unable to read shared libraries not installed by RPM. But for strict
policy the above permission doesn't help; we'd need to grant it to
everything which reads shlib_t.
That sounds a lot better :)
That is what we have with this change.
One other option besides the daemon is to have ldconfig itself do an
automatic restorecon. This is less efficient since it will do so for
every shared library, but given that ldconfig has always been the magic
command you run to make shared libraries work, it does seem somewhat of
a logical place to solve this particular problem.
An intersting idea...
Yes that would help although unfortunately some (broken?) RPMs don't run ldconfig, on the grounds that /usr/lib is always scanned by the linker regardless of what the cache says.
Long term we can push 'install' at these ISVs, and maybe around FC5 or
FC6 if we have enough success, say that that's the only supported way to
install files to the system.
I'm not keen on this line of thinking: it's the type that means
many of my Linux-native games and demos no longer run without lots of
hacking about. Is the the benefit of restricting 3rd party binaries
that don't opt-in worth the cost?
I tend to see SELinux as a tool to help enhance the security of programs that are explicitly interested in it, which goes hand in hand with a proper audit to flush out bad practice. Hopefully in future shipping policy with third party programs will become common. But I don't think it's wise to try and apply policy universally shot-gun style, especially not to legacy programs that don't expect it (which today, everything is).
thanks -mike
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
