Debian SE Linux Status

At the moment I’ve got more time to work on these things than I have had for a while.

I’ve got Etch support going quite well (see my post about my Etch repository [1]), the next step is to back-port some packages for AMD64 to get it working as well as i386.

I’ve got an i386 Xen server for SE Linux development (which is also used for my Play Machine’s [2] DomU – so it’s definitely not for anything secret). I can give accounts and/or DomU’s to people who have a good use for them (the machine has 512M of RAM so could have 4-5 DomU’s).

Currently it seems that the 2.6.24 kernel in Debian doesn’t work for Xen (at least on with an i686 CPU). I have filed bug report #472584 about it not working as a DomU [3]. This combined with the fact that according to bug report #466492 it doesn’t work as a Dom0 (which I have verified in my own tests) [4] makes the package linux-image-2.6.24-1-xen-686 unusable.

Due to the inability to use 2.6.24 Xen I can’t do SE Linux development for Lenny in a DomU (Lenny tools build policy version 21 and the Etch kernel I’m using only supports policy version 20). So I have repurposed one of my servers for Lenny (unstable) development. I can give user accounts on that machine to anyone who has a good reason (and there are some people who I would give root access to if they need it).

The current policy packages in Unstable are built without MCS support. This is a problem as converting between a policy which has MCS or MLS and one which doesn’t is rather painful (purge policy, reinstall policy, and reboot are all required steps). I have filed bug report #473048 with a patch for this – my patch may not actually be much good (I don’t understand some aspects of Manoj’s code) but it does achieve the desired result [5]. I won’t be making Apt repositories for such things as I expect that the changes will get into Debian fast enough.

The next thing I am starting to work on is MLS support for Debian (currently it only supports the Strict and Targeted policies). See the Multilevel Security Wikipedia page for some background information on the technology [6].

I don’t expect that many people will use MLS on Debian in production environments, and it wouldn’t surprise me if no-one used it on a production server (although of course it would be impossible to prove this). But I still believe that it’s worth having for educational purposes. I am sure that there are packages in Debian of a similar size that will get less use so it’s not a waste of disk space on mirror servers!

The only real down-side to adding MLS support is that it will increase the build time for the Debian SE Linux policy packages, currently they take 13 minutes to build on a 1.1GHz Celeron system (the Xen server I mentioned previously) and I expect that the machine in question will have build times greater than 20 minutes with MLS included. I will probably need to set up an Unstable DomU on a dual-core 64bit machine for the sole purpose of building policy packages. I will also have to investigate use of the “-j” option to make when building the policy to take advantage of the dual cores. I often do small tweaks to policy and it’s annoying to have to wait for any length of time for a result.

The version of Coreutils that is currently in Unstable will have ls display a “+” character for every file when running SE Linux (I have filed bug report #472590) about this [7]. It is being actively discussed and at this stage it seems most likely that the functionality from Etch in this regard will be restored (which is using “+” to represent ACLs only not SE Linux contexts). It seems likely to me that I will find a few other issues of a similar nature now that I have started seriously working on Unstable.

For the benefit of Debian and upstream developers who get involved in such discussions, please do not be put off if you join a discussion that is CC’d to the NSA SE Linux mailing list and have your message rejected by the list server. The code of conduct is much the same on most mailing lists, and the SE Linux list is not much different to others. The difference is that before your get your email address white-listed for posting you have to agree to the terms of service for the list. The people who run the list server appear to work more than 40 hours a week so there should not be a great delay. If anyone wants to get a message about Debian SE Linux development sent to the list without delay on a weekend then they can send it to me for forwarding.

I am aware of some discussions about SE Linux and the Debian installer. I have not responded to them yet because I wanted to get some serious coding done first as an approach of “I haven’t done much coding recently but trust me I’ll fix the problems for you” might not be accepted well. I will start investigating these issues as soon as I have my Debian/Unstable server working well in enforcing mode.

Update: I’ve just filed bug report #473067 with a patch to enable MLS policy builds [8].

1 comment to Debian SE Linux Status

  • I have Linux 2.6.24 Dom0 and DomU working stably with code from Ubuntu Hardy.

    Ubuntus’s Hardy code base is good minus a patch:

    Signed-off-by: Chuck Short

    …/xen/patchset/004-xen-net-fix.patch | 38 ++++++++++++++++++++
    1 files changed, 38 insertions(+), 0 deletions(-)
    create mode 100644 debian/binary-custom.d/xen/patchset/004-xen-net-fix.patch

    diff –git a/debian/binary-custom.d/xen/patchset/004-xen-net-fix.patch b/debian/binary-custom.d/xen/patchset/004-xen-net-fix.patch
    new file mode 100644
    index 0000000..996991b
    — /dev/null
    +++ b/debian/binary-custom.d/xen/patchset/004-xen-net-fix.patch
    @@ -0,0 +1,38 @@
    +diff -Naur ubuntu-hardy-xen/drivers/xen/netfront/netfront.c ubuntu-hardy-xen-new/drivers/xen/netfront/netfront.c
    +— ubuntu-hardy-xen/drivers/xen/netfront/netfront.c 2008-04-21 09:16:12.000000000 -0400
    ++++ ubuntu-hardy-xen-new/drivers/xen/netfront/netfront.c 2008-04-21 09:37:02.000000000 -0400
    +@@ -622,6 +622,7 @@
    + struct netfront_info *np = netdev_priv(dev);
    + memset(&np->stats, 0, sizeof(np->stats));
    ++ napi_enable(&np->napi);
    + spin_lock_bh(&np->rx_lock);
    + if (netfront_carrier_ok(np)) {
    +@@ -830,6 +831,8 @@
    + reservation.domid = DOMID_SELF;
    + if (!xen_feature(XENFEAT_auto_translated_physmap)) {
    ++ int j;
    + /* After all PTEs have been zapped, flush the TLB. */
    + np->rx_mcl[i-1].args[MULTI_UVMFLAGS_INDEX] =
    +@@ -847,7 +850,8 @@
    + /* Check return status of HYPERVISOR_memory_op(). */
    + if (unlikely(np->rx_mcl[i].result != i))
    + panic(“Unable to reduce memory reservation\n”);
    +- while (i–)
    ++ j = i;
    ++ while (j–)
    + BUG_ON(np->rx_mcl[i].result);
    + } else {
    + if (HYPERVISOR_memory_op(XENMEM_decrease_reservation,
    +@@ -1671,6 +1675,7 @@
    + static int network_close(struct net_device *dev)
    + {
    + struct netfront_info *np = netdev_priv(dev);
    ++ napi_disable(&np->napi);
    + netif_stop_queue(np->netdev);
    + return 0;
    + }