This is a short introduction on how to do backports yourself ------------------------------------------------------------ Backporting ----------- Backporting means bringing newer versions of some software to an older Debian release. This usually involves two kind of tasks: 1. Backport additional packages such as required libraries 2. Change dependencies to use an older version of a library While the first should always work, it eventually means you are backporting everything. You'll want to avoid doing that, but go with the second option as often as possible (since you'll have security updates by the Debian Security Team for packages you didn't replace with your own versions!). Basic Setup ----------- First of all, install "pbuilder" and create a clean build environment for your packages. Then edit /etc/pbuilderrc and setup the basics (especially which mirror to use and DEBEMAIL). Don't bother on BASETGZ or DISTRIBUTION, since we're going to override them anyway. I'm using a small script called "pbuilderse" installed in my path (to be precise: ~/.bin which I added to my $PATH) with the following contents: ---- #!/bin/sh function=$1 shift 1 exec sudo pbuilder $function --distribution stable \ --basetgz /home/pbuilder/base-selinux.tgz "$@" ---- I have similar scripts for building backports to woody, a non-SELinux-sarge and also for unstable (to have a clean build environment, while I'm also running some packages from experimental on my desktop) First of all, we need to create the build enviroment. $ pbuilderse create Then grab some coffee (depending on your internet connection and HD speed). Backporting SELinux ------------------- SELinux hasn't been around too long, making it rather independant from other applications. Also it's low-level, just some C libraries, and doesn't have huge dependencies such as Python, PHP, ... this makes it a rather easy target for backporting. When building backports, you'll have to work out the dependencies yourself (i.e. I don't know of any tool to assist you in finding out the proper build sequence for your backports, but it's not that hard - start with the libraries, then do the applications...) For SELinux, a good starting point is libselinux, which obviously is the core SELinux library. A short look at the "Build-Depends" listed in the debian/control file reveals that it only depends on "file" and the build-essential packages. Since there isn't even a version specfication on file, we can immedeately build this package for sarge. Since we don't need any changes, we could just build the package. But if you intend to upgrade the system to unstable, testing or maybe a future stable, this could give you trouble if you are using the same version number. Therefore, a good policy for backporting is to always *decrease* the version number, so that in a future upgrade the "official" version will replace your backport. (Unless of course you've made additional modifications you'll want to keep, then choose a slightly higher version or even epoch!) So I run "apt-get source libselinux", which results in a directory called "libselinux-1.26" (YMMV). I "cd" to this directory and type "dch -n" This will open the changelog in my $EDITOR and make a template entry, which I modify to look like this: libselinux (1.26-0.sesarge.1) sesarge; urgency=low * Backport for SELinux on Stable (no changes) -- Erich Schubert Thu, 17 Nov 2005 14:23:24 +0100 There are three changes here: 1. I modified the distribution field to read "sesarge", for SElinux Sarge 2. the version number was decreased from the automatic -1.1 to -0.sesarge.1, as explained above) 3. The changes description should list changes - I didn't any (except to remove some leftover arch files, which is optional) Then I save the file, close it and run "debuils -S -us -uc", this will make a source-only package, unsigned source, unsigned changes. There is no reason to sign, since I'm going to build a binary later. I now "cd .." to the container directory. There will be a couple of files here, including "libselinux_1.26-0.sesarge.1.dsc" - this file contains all the information needed by pbuilder to build the package, so I can just run "pbuilderse build libselinux_1.26-0.sesarge.1.dsc". Since the build was successful for me (YMMV, read the result), I can now remove the extracted source code: "rm -r libselinux-1.26" as well as the other source archives here. Now I copy the pbuilder-generated packages (which include the source code again, so I can indeed remove it in the previous step!) by moving them over from /home/pbuilder/result (or whichever directory you picked) In my setup I don't have move permissions. Instead I copy the files over, then use a root shell to delete the original files (yeah, moving them as root and chowning them would probably be more efficient) That was the first backport - not too bad, was it? The next backports will probably require the libselinux package we just build. Therefore, we need to modify the pbuilder chroot we created earlier. The new version reads like this: --- #!/bin/sh function=$1 shift 1 exec sudo pbuilder $function --distribution stable \ --basetgz /home/pbuilder/base-selinux.tgz \ --override-config --bindmounts "/home/foobar/debian/selinux/backports" \ --othermirror "deb file:///home/foobar/debian/selinux/backports ./" \ "$@" --- What I changed is the following: I added a new apt source to my build chroot, which will contain the backports I already did. It's stored on the local filesystem, and accessed via a "bind mount" in the filesystem. Now I have to set up this new repository, I'll use the tool "apt-ftparchive" for this. In my top level directory (/home/foobar/debian/selinux/backports) I create a file named "ftp-archive.conf" with the following contents: (copied mostly from an example file) --- Dir { ArchiveDir "/home/foobar/debian/selinux/backports"; }; Default { Packages::Compress ". gzip"; Sources::Compress ". gzip"; Contents::Compress ". gzip"; }; TreeDefault { Directory "$(DIST)/pool/"; SrcDirectory "$(DIST)/pool/"; Packages "$(DIST)/"; InternalPrefix "$(DIST)/"; Contents "$(DIST)/Contents-$(ARCH)"; }; Tree "packages" { Sections ""; Architectures "i386 all source"; Directory "$(DIST)/pool/"; SrcDirectory "$(DIST)/pool/"; Packages "$(DIST)/"; InternalPrefix "$(DIST)/"; Contents "$(DIST)/Contents-$(ARCH)"; }; BinDirectory "." { Packages "./Packages"; Sources "./Sources"; Contents "./Contents"; }; APT::FTPArchive { Release { Archive "stable"; Origin "selinux.alioth.debian.org"; Label "SELinux Sarge Backports"; Suite ""; Version "1.0"; Codename "sesarge"; Date ""; Architectures "i386 all"; Components "main"; Description ""; }; }; --- The libselinux backports I did earlier are stored in a subdir named "libselinux". Running "apt-ftparchive generate ftp-archive.conf" will result in a Packages.gz and Contents.gz files generated here. The Packages file should contain the selinux libraries you built earlier. Now we update our chroot, although it's probably not yet necessary: $ pbuilderse update Backporting further packages ---------------------------- We're going to repeat this process a couple of times now, backporting additional packages. The next target is "libsepol", a supplementary SELinux library, used by policycoreutils. This again doesn't need any special changes, and has no "serious" dependencies. $ mkdir libsepol; cd libsepol $ apt-get source libsepol $ cd libsepol-1.8 $ dch -n # update version number, distribution, document "backport, no changes" $ rm -r **/.arch-ids **/\{arch\} # optional: remove some leftover cruft to get a cleaner diff $ debuild -S -us -uc $ cd .. $ pbuilderse build libsepol_1.8-0.sesarge.1.dsc # grab some more coffee ... # hope that it doesn't say E: some error $ rm -r libsepol* $ cp /home/pbuilder/result/* . $ [as root] rm /home/pbuilder/result/* $ cd .. $ apt-ftparchive generate ftp-archive.conf # yay! done. Another backport! $ pbuilderse update # needed this time for real - libsemanage needs libsepol >= 1.8 Next in queue: libsemanage (needed for policycoreutils) $ mkdir libsemanage; cd libsemanage $ apt-get source libsemanage $ cd libsemanage-1.2 $ $EDITOR debian/control # Ohh. Something new. We have to change some dependencies! # we're caught by what I suggested earlier, because the build dependencies # are overly strict - just leave away the debian revision part for both # libselinux1-dev and libsepol1-dev (our version number is 1.24-0.sesarge.1 # which unfortunately is lower than 1.24-1 - but higher than 1.24) # this IMHO is actually a bug in libsemanage, btw. $ dch -n # this time, say we changed the dependencies slightly: # Downgraded dependencies: leave away debian revision so backport is okay $ debuild -S -us -uc $ cd .. $ pbuilderse build libsemanage_1.2-0.sesarge.1.dsc $ rm -r * $ cp /home/pbuilder/result/* . $ [as root] rm /home/pbuilder/result/* $ cd .. $ apt-ftparchive generate ftp-archive.conf # yay! done. Another backport! $ pbuilderse update # needed again Next in queue: policycoreutils This is just the same as above, we need to downgrade the dependencies here, too, by stripping away the -1 postfix. You know the drill. No need to run generate or update after this one, though. Next in queue: checkpolicy Guess what. Yep, same again. Yay! All the SELinux core packages are complete. BUT: we still need some GNU/Linux core packages backported, including pam, cron, init and ssh. Backporting Pam: No dependency downgrading here - just update the changelog and rebuild. When the verison number was 0.79-3, use 0.79-2.sesarge.1 etc. now! Backporting lsb-base: Recompile without additional changes (except the changelog) Backporting Init: *outdated*: We want to do two small changes, see http://bugs.debian.org/333836 Edit debian/initscripts/etc/init.d/checkroot.sh and debian/initscripts/etc/init.d/mountvirtfs and replace the first "touch" by "true touch" - a small hack, but the dir_writeable macro is kind of a hack, too... which might be removed in future versions. *updated*: Backporting init now is easier - above changes don't need to be done any longer -, but I found a *serious* bug in my packages: the debian/rules file needs to be modified, replace "DEB_HOST_ARCH_OS" by "DEB_HOST_GNU_SYSTEM" (this was renamed since "FreeBSD" is not GNU) Otherwise, init will be built without selinux support! Backporting Cron: Again one change to make the package more useable for SELinux: http://bugs.debian.org/333837 Edit debian/standard.daily, and wrap a "if [ -z "`which selinuxenabled`" ] || ! selinuxenabled; then" ... "fi" around the part trying to backup "shadow" and "gshadow". (read: backup only if selinuxenabled is not found or selinux is not enabled) Also cron relies on the dpkg from unstable - if you havn't backported that yet, edit debian/rules and modify DEB_HOST_ARCH_OS to use dpkg-architecture -qDEB_HOST_GNU_SYSTEM as fallback. Backporting Logrotate: Nothing special here. Just update changelog and rebuild. Backporting OpenSSH: This one is more difficult. First of all, the current unstable version depends onto the latest zlib, but (see changelog) this is just to ensure a rebuild with it; there is nothing wrong with zlib from stable. But openssh itself will also complain about a security hole in the nominal version debian sarge includes (but this has been fixed in a security update) In order to make openssh compile, we need to edit debian/rules and add the "--without-zlib-version-check" flag to both configure statements Backporting coreutils, dpkg: Both packages contain SELinux support (e.g. ps Z, ls -Z, and automatic labelling for most files during installation by dpkg) and can just be rebuilt for stable without any changes. Backporting bind9: The reason to backport bind9 is that with sarges bind9, many apps caused audit errors of the type "self:process execmem", apparently due to one of binds libraries. E.g. the bind9-host command would fail with mem.c:653: INSIST(ctx->stats[size].gets > 0U) failed. when not given the execmem privilege. But since I don't want to have to setup a separate domain just for the "host" command, I'd prefer to have a way to run it without "execmem"... I hope using the latest bind9 will resolve this. Backporting libc: There is an issue with libc that causes "execmem" failures for threaded applications. libpthread allocates stack memory for threads with PROT_READ | PROT_WRITE | PROT_EXEC, which causes the "execmem" protection to block it (this would allow code-generation on the fly, in fact this is an executeable stack) but it's a one-line diff to remove. Grab the file "nptl-no-exec.dpatch" in the glibc folder, and add it to the glibc patch directory (and to the 00list file!)