SELinux and third party installers

[Mike Hearn]

On Tue, 04 Jan 2005 18:46:27 -0500, Colin Walters wrote:
> 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.

It's a fair one. I'm coming from the perspective of competing with
Windows, but there's a whole debate here you could have about the cost vs
benefits of leaving people behind when introducing new technologies.
Arguably we don't care that much about upgrade sales because it's free
software :) so our value systems can be different. But should they be?

I don't know.
 
> 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.

Hm, OK. I should investigate why the Mono RPMs I got via apt the other day
didn't work correctly in enforcing/targetted. That sounds like a bug.

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

OK, that sounds good.

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

Long term I certainly hope strict can be the default but it's going to be
a lot of work, and it's going to raise interesting and difficult questions
about backwards compatibility.

That can wait for another day though. The ldconfig issue is fixed in CVS,
third party installers are being looked at again and that means I'm happy :)

thanks -mike