Some might have read recent news such as Novell SELinux killer rattles Red Hat, or Dan Walsh's critique of Novells AppArmor release, concerned with "unix like fragmentation in the security sector".

While I also do think that SELinux is both more mature in the core system and more powerful than AppArmor (with a big plus being that SELinux is in the vanilla kernel) - I do think that AppArmor can quickly become a true SELinux killer, by just being better documented and easier to use.

SELinux has serious deficiencies in documentation and development community. Almost all the available SELinux documentation is based around the policy as published by the NSA, which is "superseded by the reference policy project". This is the policy currently in Debian and used in the Gentoo SELinux docs - which hasn't received any updates in months now.

The newer "reference policy" is updated every few days, by exporting Tresys' internal SVN into a public CVS on sourceforge.

Dan Walsh claimed "multiple distributions shipping with SELinux including Fedora Core (2,3,4 and soon 5), Red Hat Enterprise Linux 4, Gentoo, Debian, Ubuntu, Suse and Slackware. "

Which is not entirely true. SuSE has AppArmor now, Fedora and RHEL are pretty much the same, and apparently neither Gentoo, Debian, Ubuntu or Slackware are up to date with SELinux. Or actually involved in the current development. So that basically makes 1 distribution using current SELinux and 1 distribution using AppArmor... Looks like a tie to me.

Also with the development it's pretty much down. AppArmor was developed by a small company called Immunix, and is now backed by big Novell, owner of SuSE. Current SELinux is mostly developed by a small company called Tresys, and somewhat backed and used by RedHat. Both have the feeling of "closed door" commercial development, which may be the reason why it reminds some people of the old Unix wars.

Both of course claim to do an open development, with for example the current SELinux Symposium. But if you look closely at the Agenda and the speakers, it's fairly obvious that this is pretty much a business meeting, with some university speakers talking about the security concepts used.

Just one quote from the site:

Developer Summit
An invitation only meeting for the core developers of SELinux to discuss future plans for SELinux and upcoming technologies.

The winner of this "war" between AppArmor and SELinux will be whoever manages to incorporate community development best, and get the other distributions like Debian, Ubuntu and Slackware to support their efforts. Currently neither of them has the air of actively supporting them, which is really bad. Widespread adoption is also where grSecurity has failed before.

I'm trying to put together a SELinux packaging team for Debian and Ubuntu. Current SELinux is still a major pita to get running... so we need to join our efforts in adopting policy to our needs and such.

Upstream development is of an rather "uncooperative" model: both the selinux libraries and the reference policy are updated by a single person each, by exporting an internal VCS to a public CVS on sourceforge. If you want to add patches, you always have to send them through a mailing list, and hope for them to appear in the archive sometime soon. Or not.

While this works okay for the libraries and utilities - which are fairly stable by now - I have doubts that this is appropriate for the policy. Given the amount of fixes/additions we'll need at least for the reference policy, I think more people should have write access to a shared repository. For this I've setup a subversion repository on svn.debian.org, with currently two branches: unmodified upstream and a debian branch. Note that we might also switch to an arch repository, when some big contributors prefer so.

If users of other distributions (Gentoo?) want to join, they are welcome to do so. They can have their own branch, of course, albeit I don't think it's really necessary (maybe I should have named the "debian" branch "alioth-trunk" or so...)

Basically anything is okay with me, that helps the reference policy and SELinux in picking up speed.

If you'd like to get write access, send me an email with your alioth user id. Given the "unmodified upstream" branch, it should be fairly easy to extract patches from our repository to be included upstream, too.