I have just finished updating the user-space SE Linux code in Debian/Unstable to the version released on 2012-02-16. There were some changes to the build system from upstream which combined with the new Debian multi-arch support involved a fair bit of work for me. While I was at it I converted more of them to the new Quilt format to make it easier to send patches upstream. In the past I have been a bit slack about sending patches upstream, my aim for the next upstream release of user-space is to have at least half of my patches included upstream – this will make things easier for everyone.

Recently Mika Pflüger and Laurent Bigonville have started work on Debian SE Linux, they have done some good work converting the refpolicy source (which is used to build selinux-policy-default) to Quilt. Now it will be a lot easier to send policy patches upstream and porting them to newer versions of the upstream refpolicy.

Now the next significant thing that I want to do is to get systemd working correctly with SE Linux. But first I have to get it working correctly wit cryptsetup.

Since my last SE Linux in Debian status report [1] there have been some significant changes.

Policy

Last year I reported that the policy wasn’t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn’t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released.

Kernel

Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though.

As the kernel silently ignores command line parameters that it doesn’t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it’s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won’t work with SE Linux.

As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven’t needed to be changed for 6 years! SE Linux isn’t a new thing, it’s been in production for a long time.

Audit

While the audit daemon isn’t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future.

Libraries

There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I’m sure that I will notice soon enough if they don’t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing.

Play Machine

I am now preparing a new SE Linux “Play Machine” running Debian/Unstable. I wore my Play Machine shirt at LCA so I’ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I’ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

• [1] http://etbe.coker.com.au/2011/10/31/selinux-status-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!

Currently Debian/Unstable is going through a transition to using /run instead of /var/run. Naturally any significant change to the filesystem layout requires matching changes to SE Linux policy. We currently have Debian bug #626720 open about this. Currently the initscripts package breaks selinux-policy-default in Debian/Unstable so that you can’t have initscripts using /run if the SE Linux policy doesn’t support it.

A patch has been suggested to the policy which uses a subst file, basically that causes the SE Linux labeling programs to treat one directory tree the same way as another. The problem with this is that it depends on a libselinux patch that is not in any yet released version of libselinux (and certainly won’t be in a Squeeze update). The upside of such a fix is that it would work for policy that I package as well as custom policy, so if someone wrote custom policy referring to /var/run it would automatically work with /run without any extra effort.

I think that the only way to do this is to just have regular expressions that deal with this in the file contexts. It’s a bit ugly and slows the relabel process down a little (probably no more than about 10%) but it will work – and work on Squeeze as well. One thing I really like to do is to have the SE Linux policy for version X of Debian work with version X+1. This makes upgrades a lot easier for the users. Ideally upgrading a server could be a process that involves separate upgrades of the kernel, the SE Linux policy, and user-space in any particular order – because upgrading everything at once almost guarantees that something will break and it may be difficult to determine the cause.

At this time I’m not sure whether I’ll add a new policy using the subs file before the release of Wheezy (the next stable release of Debian) or just keep using regular expressions. I can have the Wheezy policy depend on a new enough libselinux so it won’t be a problem in that regard (a new upstream version of libselinux with the subst feature should be released soon). In any case I need a back-port to Squeeze to use regular expressions to make an upgrade to Wheezy easier.

for n in $(find . -name "*.fc"|xargs grep var/run|cut -f1 -d:|uniq) ; do
  sed -e "s/\/var\/run/\/(var\/)?run/" < $n > $n.new
  mv $n.new $n
done
for n in $(find . -name "*.fc"|xargs grep var/lock|cut -f1 -d:|uniq) ; do
  sed -e "s/\/var\/lock/\/((var\/run)|(run)|(var))\/lock/" < $n > $n.new
  mv $n.new $n
done
for n in $(find . -name "*.fc"|xargs grep dev/shm|cut -f1 -d:|uniq) ; do
  sed -e "s/\/dev\/shm/\/((var\/run)|(run)|(dev))\/shm/" < $n > $n.new
  mv $n.new $n
done

I used the above fragment of shell code to change “/var/run” to “/(var/)?run”, “/var/lock” to “/((var/run)|(run)|(var))/lock”, and change “/dev/shm” to “/(var/run)|(run)|(dev))/shm”. It involves a reasonable number of changes to policy (mostly for /var/run), but hopefully this will be acceptable to the release team for inclusion in the next Squeeze update as the changes are relatively simple and obvious and the size of the patch is due to it being generated code.

There is one final complication, Squeeze currently has selinux-policy-default version 2:0.2.20100524-7+squeeze1, but initscripts in Unstable breaks versions <= 2:0.2.20100524-9. So I guess I could submit a proposed version 2:0.2.20100524-9+squeeze1 to the release team to fix this. I would really like to have the Squeeze policy work with initscripts from Unstable or Wheezy.

Any suggestions for how to deal with this?

Update:

I wrote the above before testing the code, and it turned out to not work. I’ve written another post describing a better solution that I have now uploaded to Unstable. I still have to sort something out with an update for Squeeze.

Joey has proposed a new concept of “Continuously Usable Testing” for Debian [1], basically testing should be usable at all times and packages that aren’t usable should be dropped. But to properly achieve this goal we need continual testing of usability.

The Plan For SE Linux

To do this for SE Linux I’m setting up a Xen server which will have a number of different DomUs for testing a variety of server applications. The system has 1.5G of RAM and 160G of mirrored storage. An image of a typical server will take about 4G of disk space, so we could have something like 40 images online and ready for testing. I have already setup Squid on another system on the same LAN to cache Debian packages, so running “apt-get dist-upgrade” on a number of DomUs won’t take that long. With 256M for a typical server image I could have 5 images running at the same time. If the hardware isn’t enough then I can expand it, I hope to get some donations of DDR-266 or DDR-333 RAM (or maybe DDR-400) to upgrade the system to 4G of RAM, I can add more hard drives, and I could even install more servers.

I want to have testing be very usable for SE Linux throughout the development cycle so that I don’t have to rush things before release.

At this stage I’m not sure whether to track Unstable or Testing for this. I guess it might be best to track Testing most of the time and only track Unstable for daemons that are changing rapidly. It might get boring testing every version that comes through Unstable, but if people want to do this then I won’t stop them.

Setting up the Tests

What I need are interested people who want to install server configurations for testing. If you have some favorite combination of daemons that you want tested for SE Linux support (even if it’s daemons that have no current policy) then I can give you root access to a DomU to develop test cases. Ideally there would be automated tests used for most things for example testing a mail server by using swaks to deliver mail and a POP or IMAP client script to retrieve it. But some things can’t be tested properly without human intervention.

For the automated tests I want to script the creation of DomUs, upgrading the packages in the DomU, testing it, and then shutting down the DomU if it all works. If at any time the tests fail (or the upgrade fails) then it would wait for human intervention. That would be me fixing SE Linux problems and other people fixing the application problems. I think that discovering SE Linux issues will only be a part of this project.

For the manual tests I will grant access to create and destroy the DomUs in question to people who can run the tests.

I’m thinking of having a couple of DomUs running permanently for things which are test candidates but also useful for the project, such as a MediaWiki instance. It really depends on the interest of people who might use such things.

Also I’m thinking of setting up some Ubuntu DomUs too, I probably should join Ubuntu and get involved with SE Linux there.

Sharing the Images

I have a web server in Germany with almost unlimited bandwidth and storage. For every image that is created I want to upload a version to the server in Germany to allow anyone in the world to test it. There are lots of possible ways of using this for software development. For example if you had a patched version of Apache that you wanted to test then you could download every image that had Apache installed and test that they all work. That would be easier than configuring Apache in different ways and also possibly provide better coverage.

Also if someone can’t figure out how to configure a daemon correctly then downloading a Xen image of a working configuration could be helpful (if a little bandwidth intensive). Note that deploying such an image in production would be a really bad idea, among other things there are lots of places where passwords are stored and you wouldn’t want to risk missing one.

I also plan to share the scripts used in running the Dom0 and anything else that seems useful along the way.

What We Need

The main thing we need is volunteers to configure virtual machines with their favorite daemons. Note that I don’t plan to have only one daemon per DomU, if we can get multiple daemons running that don’t conflict (EG file server and mail server) or multiple daemons that can interact (EG database server and a mail server or anything else that can be a database client) running on the same system then that’s a good thing. So there will be some degree of interaction with other people.

I’m happy to accept contributions from people who aren’t interested in SE Linux. But SE Linux will run on all DomUs.

Finally I also need more RAM for a HP D530S, DU875PA (that’s a Celeron 2.4GHz). I’ll accept donations of complete systems too once my HP system gets full, preferably relatively low power systems as they will be housed in a location that’s not as well ventilated as I would like (cost and availability of IP addresses were the main criteria). A laptop with a broken screen would be great!

The system won’t go live until Monday, but I think that probably people won’t be ready to do much work with less than two days notice anyway.

• [1] http://kitenet.net/~joey/code/debian/cut/

A recent development in SE Linux policy is the concept of UBAC (User Based Access Control) which prevents SE Linux users (identitied) from accessing each other’s files.

SE Linux user identities may map 1:1 to Unix users (as was required in the early versions of SE Linux), you might have unique identities for special users and a default identity for all the other users, or you might have an identity per group – or use some other method of assigning identities to groups.

The UBAC constraints in the upstream reference policy prevent a process with a SE Linux identity other than system_u from accessing any files with an identity other than system_u. So basically any regular user can access files from the system but not other users and system processes (daemons) can access files from all users. Of course this is just one layer of protection, so while the UBAC constraint doesn’t prevent a user from accessing any system files the domain-type access controls may do so.

If you used a unique SE Linux identity for each Unix account then UBAC would prevent any user from accessing a file created by another user.

For my current policy that I am considering uploading to Debian/Unstable I have allowed the identity unconfined_u to access files owned by all identities. This means that unconfined_u is an identity for administrators, if I proceed on this path then I will grant the same rights to sysadm_u.

UBAC was not enabled in Fedora last time I checked, so I’m wondering whether there is any point in including it – I don’t feel obliged to copy everything that Fedora does, but there is some benefit in maintaining compatibility across distributions.

For protecting users from each other it seems that MCS (which is Mandatory in the Debian policy) is adequate. MCS allows a much better level of access control. For example I could assign categories c0 to c10 to a set of different projects and allow the person who manages all the projects to be assigned all those categories when they login. That user could then use the command “runcon -l s0:c1 bash” to start a shell for the purpose of managing files from project 1 and any file or process created by that command would have the category c1 and be prevented from writing to a file with a different category.

Of course the down-side to removing UBAC is that since RBAC was removed there is no other way of separating SE Linux users, while MCS is good for what it does it wasn’t designed for the purpose of isolating different types of user. So I’ll really want to get RBAC reinstalled before Squeeze is released if I remove UBAC.

Regardless of this I will need to get RBAC working on Squeeze eventually anyway. I’ve had a SE Linux Play Machine running with every release of SE Linux for the last 8 years and I don’t plan to stop now.

I have just filed Debian bug report #556644 against the version of openssh-server in Debian/Unstable (Squeeze).  It has a patch that moves the code to set the SE Linux context for the child process before calling chroot. Without this a chroot environment on a SE Linux system can only work correctly if /proc and /selinux are mounted in the chroot environment.

deb http://www.coker.com.au squeeze selinux

I’ve created the above APT repository for Squeeze which has a package that fixes this bug. I will continue to use that repository for a variety of SE Linux patches to Squeeze packages, at the moment it’s packages from Unstable but I will also modify released packages as needed.

The bug report #498684 has a fix for a trivial uninitialised variable bug. The fix is also in my build.

Also I filed the bug report #556648 about the internal version of sftp being
incompatible with SE Linux (it doesn’t involve an exec so the context doesn’t change). The correct thing to do is for sshd to refuse to run an internal sftpd at least if the system is in enforcing mode, and probably even in permissive mode.

deb http://www.coker.com.au lenny selinux

Update: I’ve also backported my sshd changes to Lenny at the above APT repository.