On Thu, 18 Oct 2007, Nicolas Mailhot wrote:
Le jeudi 18 octobre 2007 à 10:57 +0300, Panu Matilainen a écrit :
On Thu, 18 Oct 2007, Nicolas Mailhot wrote:
You could make the same arguments for user names, unix permissions or
file location — a lot them have different values in the wild than in
Fedora and yet we store our policy in rpm.
The difference here is that we don't even try to support several
different policies (including custom local policies on top of the distro
policies) for user names, permissions etc. If we did, we'd be in the very
same swamp as with SELinux currently.
And the swamp root is not in-spec definition of our security policy the
swamp root is trying to manage several set of security policies without
getting one right distro-wide first.
The more I think about it the more I'm convinced we should have started
by adopting a lax Fedora selinux policy (and get it supported by all
packages and distro tools including getting selinux labels in-spec like
all our other policies) and then spent the following releases tightening
it instead of doing all at once, compromising on tool support to be a
jack-of-all-trades, and get nowhere.
We don't do file relocation. We don't do debian suggests. We forced a
single encoding on everyone. We don't do a lot of things that would mean
letting users choose instead of getting our Fedora policy right.
For selinux we went the other way and everyone can see the resulting
disaster.
I'm not claiming there is no problem. What I'm saying is that storing the
labels within RPM doesn't fix a thing.
It stops the pretense selinux is special and can not be integrated
properly.
It'll stop the pretense alright, by breaking all over the place as
things currently are ;)
Mind you, I don't think we're in that much disagreement really, just
different POV. If each package were fully in control of it's own policies,
storing the labels in packages themselves might make sense. But then to
create new policies, you'd have to make changes to every single package
instead of just creating + updating a single central policy.
It's not entirely unlike the case of package translations: having them in
specs themselves vs specspo both have severe issues, specspo is used
because the alternative is just so impossible in practise.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
