If you are maintinaing of developing a Fedora Package.

[Panu Matilainen]

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 -