SELinux and third party installers

[Colin Walters]

On Tue, 2005-01-04 at 22:51 +0000, Mike Hearn wrote:
> On Tue, 04 Jan 2005 15:08:01 -0500, Colin Walters wrote:
> >> 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.
> 
> That works when the vendor is around and keen to give you free bugfix
> updates, but often they're not, eg Loki (or if your support period
> expired).

Ok.  I don't think it would be a big deal to write this off in say two
years, but that's just my opinion.

> > 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.
> 
> Yes that'd be good although my understanding of strict is that programs
> without policy won't work, ie third party RPMs created before SELinux,

The labeling happens at install time, so even RPMs created before
SELinux will be labeled correctly, assuming that the files contained in
the RPM are "typical" files such as shared libraries in /usr/lib or
binaries in /usr/bin.

> games from Loki/GarageGames or whatever. Or at least won't work without a
> lot of tweaking.

Well, it depends.  System daemons will definitely require policy to run.
But regular user binaries run unmodified; e.g. very little in all of
GNOME was changed.

> > 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.
> 
> Right, by "shipping policy with third party programs" I meant they write
> their own policy. I seem to remember arguing about this with Russell
> before though :)

Yes, it's a whole other debate.

> > I run strict policy (i.e. universally shot-gun style ;)) on my server,
> > it works quite well.
> 
> Sure but that's a server, which I guess is fairly typical web+mail+ssh+a
> few other things, right? 

Right.

> When you only run a relatively small set of
> programs all provided by a central source it's a lot easier to do that. 
> I want to see SELinux on desktops, which means working with all the random
> software the user has :)

So do I, and I think we're actually a lot closer to that than some of
the discussions here might make one think.

Strict policy should work very well today on something like a kiosk,
where the set of software is fixed in advance, tested, and users are
tightly restricted in what they can do.  A typical knowledge worker
desktop should for the most part just work.  But a developer workstation
(what most of us on this list use) is far more difficult.  Particularly
for Fedora developers, because we're changing the base OS itself.

Besides people doing various things with Apache, this shlib_t issue is
probably the biggest problem we've seen, and I think we have a mostly
acceptable workaround for now with Dan's latest policy.