On Tue, 2005-01-04 at 19:43 +0000, Mike Hearn wrote: > 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. If it's installed via RPM it will be labeled automatically. > > 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 don't expect you to do this hacking; I'd expect the vendor to do it. > I tend to see SELinux as a tool to help enhance the security of programs > that are explicitly interested in it, That's what the targeted policy does essentially. But SELinux is capable of a lot more than that; e.g. giving the ability to define a "webmaster" role with only the access necessary to administer Apache. So it would be good to fix this problem in a generic way so it works in targeted and strict. If we can fix enough of these kinds of speedbumps, I feel that strict could be usable by a much wider range of people. > 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. Mmm. I think the interesting question isn't where the policy binary bits are stored (in individual .rpm packages versus one big blob in selinux-policy-targeted RPM), but who writes the source. > 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). I run strict policy (i.e. universally shot-gun style ;)) on my server, it works quite well.
