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