SELinux and third party installers

Mike Hearn mike at navi.cx
Tue Jan 4 19:43:31 UTC 2005


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?

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 at 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 :)

> 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.

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




More information about the fedora-selinux-list mailing list