It’s almost the Wheezy freeze time and I’ve been working frantically to get things working properly.
At the moment I’m preparing an upload of the policy which will support KDE (and probably most desktop environment) logins and many little fixes related to server operations (particularly MTAs). I would like to get another version done before Wheezy is released, but if Wheezy releases with version 2.20110726-6 of the policy that will be OK. It will work well enough for most things that users will be able to use local changes for the things that don’t work.
One significant lack with the current policy is that systemd won’t work. I’ve included most of the policy changes needed, but haven’t done any of the testing and tweaking that is necessary to make it work properly.
I would like to see policy support for systemd in a Wheezy update if I don’t get it done in time for the first release. If I don’t get it done in time for the release and if the release team don’t accept it for an update then I’ll put it in my own repository so anyone who needs it can get it.
One significant change for Wheezy is to use a tmpfs mounted on /run instead of /var/run. This means that lots of daemon start scripts create subdirectories of /run at boot time which need to have SE Linux labels applied for correct operation. The way things work is that usually the daemon will write to the directory immediately after the init script has created it, so I can’t just have my own script recursively relabel all of /run.
[ -x /sbin/restorecon ] && /sbin/restorecon -R $DIR
Generally if you are writing an init script and creating a directory under /run then you need to have some shell code like the above immediately after it’s created. Also the same applies for directories under /tmp and any other significant directories that are created at boot time.
Currently there are some potential problems with the upgrade process, I’m working on them at the moment. Ideally an “apt-get dist-upgrade” would cleanly upgrade everything. But at the moment it seems likely that the upgrade might initially go wrong and then work on the second try. There are some complications such as the selinux-policy-default package owning a config file which is used by mcstransd (which is part of the policycoreutils package), when the config file format changes you get order dependencies for the upgrade.
My aim when developing a new SE Linux release for Debian is that the policy should work as much as possible with the user-space from the previous release. So if you upgrade from Squeeze to Wheezy you should be able to start the process by upgrading the SE Linux policy (which drags in the utilities and lots of libraries). This means that if you have a server running you don’t have to put it out of action for the entire upgrade, you can get the policy going and then get other things going. I haven’t tested this yet but I don’t expect any problems (apart from all the dependencies).
Also the policy should work with the kernel from the previous release. So if you have a virtual server where it’s not convenient to upgrade the kernel then that shouldn’t stop you from upgrading the user-space and the SE Linux policy. I’ve tested this and found one bug, the sepolgen-ifgen utility that you need to run before audit2allow -R won’t work if the kernel is older than the utilities #677730. I don’t know if it will be possible to get this fixed. Anyway it’s not that important, you can always copy the audit log to another system running the same policy to run audit2allow, it’s not convenient but not THAT difficult either.
The End Result
I think that the result of using SE Linux in Wheezy will be quite good for the people who get the upgrade done and who modify a few init scripts that don’t get the necessary changes in time. I anticipate that someone who doesn’t know much about SE Linux will be able to get a basic workstation or small server installation done in considerably less than an hour if they read the documentation and someone who knows what they are doing will get it done in a matter of minutes (plus download and install time which can be significant on old hardware).
At the moment I’m in the process of upgrading all of my systems to Unstable (currently Testing has versions of some SE Linux packages that are too broken). While doing this I will keep discovering bugs and fix as many of them as possible. But it seems that I’ve already fixed most things that affect common users.
Also BTRFS works well. Not that supporting a new filesystem is a big deal (all that’s needed is XATTR support), but having all the nice new features on one system is a good thing. Now I just need to get systemd working.