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