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