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.