SE Linux Status in Debian 2011-10

Debian/Unstable Development

deb wheezy selinux

The above APT sources.list line has my repository for SE Linux packages that have been uploaded to Unstable and which will eventually go to testing and then the Wheezy release (if they aren’t obsoleted first). I have created that repository for people who want to track SE Linux development without waiting for an Unstable mirror to update.

In that repository I’ve included a new version of policycoreutils that now includes mcstrans and also has support for newer policy such that the latest selinux-policy-default package can be installed. The version that is currently in Testing supports upgrading policy on a running system but doesn’t support installing the policy on a system that previously didn’t run SE Linux.

I have also uploaded SE Linux Policy packages from upstream release 20110726 compared to the previous packages which were from upstream release 20100524. As the numbers imply there is 14 months of upstream policy development which changes many things. Many of the patches from my Squeeze policy packages are not yet incorporated in the policy I have uploaded to Unstable. I won’t guarantee that an Unstable system in Enforcing mode will do anything other than boot up and allow you to login via ssh. It’s definitely not ready for production but it’s also very suitable for development (10 years ago I did a lot of development on SE Linux systems that often denied login access, it wasn’t fun).

Kyle Moffett submitted a patch for libselinux which dramatically changed the build process. As Manoj (who wrote the previous build scripts) was not contactable I accepted Kyle’s patch as provided. Thanks for the patch Kyle, and thanks for all your work over the years Manoj. Anyway the result of these changes should mean that it’s easier to bootstrap Debian on a new architecture and easier to support multi-arch – but I haven’t tested either of these.


The policy packages from Squeeze can’t be compiled on Unstable. The newer policy compilation tool chain is more strict about how some things can be declared and used, thus some policy which was fairly dubious but usable is now invalid. While it wouldn’t be difficult to fix those problems I don’t plan to do so. There is no good reason for compiling Squeeze policy on Unstable now that I’ve uploaded a new upstream release.

deb squeeze selinux

I am still developing Squeeze policy and releasing it in the above APT repository. I will also get another policy release in a Squeeze update if possible to smooth the transition to Wheezy – the goal is that Squeeze policy will be usable on Wheezy even if it can’t be compiled. Also note that the compilation failures only affect the Debian package, it should still be possible to make modules for local use on a Wheezy system with Squeeze policy.


On Wednesday I’m giving a lecture at my local LUG about MLS on SE Linux. I hope to have a MLS demonstration system available to LUG members by then. Ideally I will have a MLS system running on a virtual server somewhere that’s accessible as well as a Xen/KVM image on a USB stick that can be copied by anyone at the meeting.

I don’t expect to spend much time on any aspect of SE Linux unrelated to MLS for the rest of the week.

Version Control

I need to change the way that I develop SE Linux packages, particularly the refpolicy source package (source of selinux-policy-default among others). A 20,000 line single patch is difficult to work with! I will have to switch to using quilt, once I get it working well it should save me time on my own development as well as making it easier to send patches upstream. Also I need to setup a public version control system so I can access the source from my workstation, laptop, and netbook. While doing that I might as well make it public so any interested people can help out. Suggestions on what type of VCS to use are welcome.

How You Can Help

Sorting out the mess that is the refpolicy package, sending patches upstream and migrating to a VCS is a fair bit of work. But there are lots of small parts. Sending patches upstream is a job that could be done in small pieces.

Writing new policy is not something to do yet. There’s not much point in doing that while I still haven’t merged all the patches from Squeeze – maybe next week. However I can provide the missing patches to anyone who wants to review them and assist with the merging.

I have a virtual server that has some spare capacity. One thing I would like to do is to have some virtual machines running Unstable with various configurations of server software. Then we could track Unstable on those images and use automated testing to ensure that nothing breaks. If anyone wants root access on a virtual server to install their favorite software then let me know. But such software needs to be maintained and tested!

5 thoughts on “SE Linux Status in Debian 2011-10”

  1. Regarding VCS I think it would definitely make sense to use git, as upstream refpolicy is using it. I found myself in a need to port newer versions of refpolicy to debian and I did so with git which makes it particularily easy to back-port patches from the latest master refpolicy to my local debian packages. (Well, this doesn’t apply anymore too well because of the changed directory layout an generally the split between core modules and the rest usually now porting patches from master to refpolicy-2010-12-13 needs some manual steps.)
    Apparently, when Manoj did the SELinux work, he used git too, at least I could find some old selinux debian packaging trees from him hanging around when searching for some kind of debian-delta that was easier to consume than the bare massive patch (which I eventually used).

    Regarding automated testing etc. I might be interested in setting up a postfix+dovecot-deliver+spamass-milter combination, but I guess I should first try to upstream my policy changes there, as particularily dovecot-deliver doesn’t work well out of the box atm. Also, I’ve never done more automatic testing than just sending mail via SMTP and see if the server accepts it. Unfortunately, that doesn’t guarentee that postfix can actually deliver the mail. But if that is a server combination that sounds interesting to you, I would be willing to set it up and see how far I come with current unstable policy.

  2. Mika: Thanks for the information about git, that sounds promising. Would you be able to help me with this conversion?

    My email is stored on a system running Postfix+courier-maildrop+spamass-milter+mysql+sasl and it’s been running correctly in enforcing mode for ages.

    One of my clients has systems running Postfix+dovecot-deliver+mysql+sasl+perdition+apache+webmail in enforcing mode (although the LMTP server is running as initrc_t). Postfix stuff works well on SE Linux and is well tested.

    One thing I’ve been wanting to do for ages is to get Exim working properly.

  3. Yes, I could help with converting to git, of course. You do see the email I post here, do you? (kinda strange: I ticked the “Notify me of followup comments via e-mail” box but didn’t get any mail)

    Regarding postfix, I have to say that stuff works very well, although atm I’m trying to sort out some problems with spamass-milter. But I guess when you are testing postfix+dovecot-deliver already, it doesn’t make a whole lot of sense if I set up almost the same combination for testing again.

  4. When I reinstalled my blog server I forgot to set the boolean to allow Apache to send mail…

    How do we start the conversion to git?

  5. Hi Russell,

    Thank you for taking the time and trouble to keep selinux going on debian. I’m an SE newbie.

    I can’t see where you have a sealert and setroubleshootd around. Doesn’t appear to be in your repo.
    Where might I find it?

    Thanks in advance

Comments are closed.