SELinux and third party installers

[Colin Walters]

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.