getting big changes in Debian
Erich Schubert comments on the issues relating to getting big changes into Debian. This is something that I had also noticed. I started work on SE Linux in Debian in 2001 and continued it actively until 2003 when I joined Red Hat. Less than a year after I joined Red Hat there was a Fedora release with SE Linux fully integrated and shortly after that there was a release with SE Linux on by default. The reason for this was that Red Hat management supported the idea of SE Linux and everyone had to accept it. There was no option for a package maintainer to refuse to support SE Linux.
Recently in a discussion on debian-devel one DD (who I won't name in this blog post) advocated removing SE Linux support from dpkg. I then asked him whether he had the same attitude towards non-executable stack
(Exec-Shield/PaX/OpenWall), Poly-Instantiated directories, and PIE executables. When he expressed interest in having those features I pointed out that one of the enemies of security in Debian is the fact that every person controls their little area and has no requirement to work towards common goals (apart from the most obvious ones of making the system work).
This means that instead of having a little cooperation from other developers anyone who wants to get a significant change included will have to fight hundreds of battles.
SE Linux is a classic example of this. Debian could have had SE Linux support long before Fedora, but instead it gets it long afterwards.
The same battles occur with regard to all the other security measures I mentioned (and some others I didn't). We could made Debian the most secure Linux distribution, there are many people who have the skills and the interest in doing so.
If you want features such as exec-shield, then you are missing out - largely because the people with the skill and time to work on them are too busy fighting trench-warfare rather than actively coding.
Now while I strongly object to most incarnations of the "you can't force a volunteer to do anything" meme that infects Debian I do agree that we can't force developers to write new code. We can however strongly discourate an antagonistic attitude towards new features. If someone proposes a feature
that you don't plan to use but which doesn't hurt you then there's no reason to attack - you can just ignore it. If someone sends in a patch that adds a feature which is requested by many people but you personally don't use, then if it has little or no down-side (linking against a couple of shared objects as is the case for many SE Linux enabled programs provides no measurable overhead) and the code is good it should be merged!
The real problem is that some DDs are more concerned about what is best for them personally (in the most short-term manner) than about what is best for the users.
6 comments:
Perhaps something like SELinux that affect $NUMBER of packages, should garner support by one of these way:
DPL support, RM support, or a GR to show support. Once an initiative has some visible support (preferably by 2 of the above), it should be made a release goal and at that point any developer working against it should be brought to the tech-ctte. How can it benefit Debian to have developers that block release goals if they want Debian to move forward? If there is cause shown that a change is far more damaging, then it certainly can be shown in a clear technical way that any DD can see. If that is not shown, the package needs to find a maintainer that supports release goals or they should agree to add an additional person(co-maint) to help them with adding support for the release goal.
Kevin: SELinux support is a release goal for etch.
Russell: I have no particular interest in SELinux, and I don't know how to use it. If someone sent me a patch to add SELinux support, how would I test it? Maybe it's something more I have to learn.
In response to Ben's comments:
It appears that the goal for Etch was 'to have "support"' which is different then having it activated with targeted mode like in REL (for multiple versions). Its like installing a firewall but never turning it on. Also, I'm sure that Russell or maybe Erich would have helped IMO with the testing in the creation of SELinux policy modules.
-K
One thing I've always found strange about SELinux support in Debian is that the policy is all centralised. It may be that there's a good technical reason for this but I've never seen it and it always struck me as surprising.
The skill in writing policy is also fairly centralised at this time.
As more DDs gain skills in writing policy we can change things in this regard.
That seems like a self-fulfilling prophecy - by discouraging less strongly interested people from learning about SELinux rules you'd seem to be reducing the general skill pool. I know one of the reasons I've not looked at SELinux too much is that there's nothing in particular that it allows me to do anything, nor is there anything I'm particularly expected to do as a developer.
As things stand SELinux tends to come over as something that's really hard to engage with.
Post a Comment