Archives

Categories

SE Linux in Lenny Status

SE Linux is almost ready to use in Lenny. Currently I am waiting on the packages libsepol1 version 2.0.30-2, policycoreutils 2.0.49-3, and selinux-policy-default version 0.0.20080702-4 to make their way to testing. The first two should get there soon, the policy will take a little longer as I just made a new upload today (to make it correctly depend on libsepol1 and also some policy fixes).

Update: libsepol1 version 2.0.30-2 and policycoreutils 2.0.49-3 are now in Lenny (testing). Now I’m just waiting for the policy.

Ideally we would be able to pin the apt repositories to take just the packages we want from Unstable (here is a document on how it’s supposed to work [1]). That doesn’t work, so I also tried setting “APT::Default-Release “stable”;” in /etc/apt/apt.conf (as suggested on IRC). This gave better results than pinning (which seems to not work at all) but it still wanted to take unreasonably large numbers of packages from unstable.

Currently to get SE Linux in Lenny (Testing) working you must first upgrade everything to the testing versions, then install libsepol1 from Unstable (this is really important as until a few hours ago the Policy packages in Unstable didn’t depend on it). Then you install policycoreutils and finally the policy package which will be selinux-policy-default for almost everyone – I have not tested the MLS package (selinux-policy-mls) and it’s quite likely that it won’t work well.

The policycoreutils package has a bug related to Python libraries [2] which I don’t know how to fix. Any advice would be appreciated. It’s obvious that the package name needs to not contain a hyphen, but what the name should be and where the files should be stored. The release team have been pretty cooperative with my requests so far to get broken things fixed, hopefully I’ll find a solution to this (and the other similar issues) soon enough to avoid any great inconvenience to them. I’m sure that they will agree that significantly broken packages (which have syntax errors in scripts) need to be fixed before release.

There are also some last minute policy issues that need to be fixed. To properly test this I’m now running the server for my blog and mail server on Lenny with SE Linux. I think that I’m only one policy bug away from running in enforcing mode.

While the situation is pretty difficult at the moment (I’ve had a report forwarded to me from an OLS delegate who tried Lenny SE Linux with the older policy packages and got a bad result), I believe that once Lenny is released we will have the best ever support for SE Linux.

The Debian security team recently released an update to the SE Linux policy packages to match the recent updates to BIND [3]. I was grateful that they did this – and without any significant involvement from me. I was asked to advise on the patch that they had written, I confirmed that it looked good (which took hardly any effort), and they did the rest (which appears to be a moderate amount of work). Given the situation it would have been understandable if they had decided that it was something that could be worked around.

I expect that SE Linux on Lenny will get more users than on Etch, so therefore more issues of this nature will be discovered so I expect to have more interaction with the Debian security group in future.

4 comments to SE Linux in Lenny Status

  • Israel Vinícius Nogueira Miranda

    Ok, I recognize apt pinning mechanism is a little difficult to set up but once configured works perfectly. Apt pinning is one of my favorite debian features, I had done many exotic configurations with it along the way, and they all worked as expected.
    For apt pinning work pulling the packages from testing preferentially you have to set unstable priority 100~150.

    http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html

    I have a workstation with lenny and I only pull packages from unstable that are not available in testing yet. Some time ago that was the case for ecplise-cdt . There follows my /etc/apt/preferences file:

    Package: *
    Pin: release o=Debian,a=lenny
    Pin-Priority: 900

    Package: *
    Pin: release o=Debian,a=testing
    Pin-Priority: 900

    Package: *
    Pin: origin http://www.debian-multimedia.org
    Pin-Priority: 750

    package: *
    Pin: origin download.skype.com
    Pin-Priority: 750

    package: *
    Pin: origin deb.opera.com
    Pin-Priority: 750

    package: *
    Pin: origin http://ftp.debian-unofficial.org
    Pin-Priority: 750

    Package: *
    Pin: release o=Debian,a=stable
    Pin-Priority: 600

    Package: *
    Pin: release o=Debian,a=etch
    Pin-Priority: 600

    Package: *
    Pin: release o=Debian,a=oldstable
    Pin-Priority: 500

    Package: *
    Pin: release o=Debian,a=sarge
    Pin-Priority: 500

    Package: *
    Pin: release o=Debian,a=unstable
    Pin-Priority: 150

    Package: *
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1

    With a priority lesser than 100 packages will only be installed if there is no other version available, but will not get upgraded. If you set a priority greater than 100 packages will be upgraded when there is a newer version available in the repository(says, a unstable package gets a newer version, but it hasn’t gone to testing yet).
    I use Debian Unstable at home pulling kde4 packages from experimental, there goes the /etc/apt/preferences file:

    Package: *
    Pin: release o=Debian,a=unstable
    Pin-priority: 900

    Package: *
    Pin: release o=Debian,a=testing
    Pin-Priority: 800

    Package: *
    Pin: origin http://ftp.debian-unofficial.org
    Pin-Priority: 600

    Package: *
    Pin: origin http://www.debian-multimedia.org
    Pin-Priority: 600

    Package: *
    Pin: origin download.skype.com
    Pin-Priority: 550

    Package: *
    Pin: origin deb.opera.com
    Pin-Priority: 550

    Package: *
    Pin: origin apt.last.fm
    Pin-Priority: 550

    Package: *
    Pin: release o=Debian,a=stable
    Pin-priority: 500

    Package: *
    Pin: release a=etch-backports
    Pin-Priority: 450

    Package: *
    Pin: release o=Debian,a=experimental
    Pin-priority: 101

    Package: kde4
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: extragear-plasma
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdeadmin
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdeartwork
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdeedu
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdegames
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdegraphics
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdemultimedia
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdenetwork
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: kdeutils
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: ark
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    Package: koffice
    Pin: release o=Debian,a=experimental
    Pin-Priority: 1001

    *Note that I use meta-packages

  • etbe

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487212

    Tom Parker drew my attention to the above bug (with patch). Strangely I had tested something that was almost identical and had it fail. Oh well, it was late at night and I guess I messed up my tests.

    I’ll upload a new package now.

  • etbe

    I’ve uploaded policycoreutils_2.0.49-4 and sepolgen_1.0.11-4 to fix this.

  • […] Coke oznámil, že SELinux pro Debian Lenny je téměř dokončen. V repositářích je už správná verze knihovny libsepol1 a utilit policycoreutils. Jediné, co […]