SE Linux Status in Debian 2011-10

Debian/Unstable Development

deb http://www.coker.com.au 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.

Squeeze

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 http://www.coker.com.au 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.

MLS

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!