Firstly I think it’s useful to consider some other large packages that could be split into multiple packages. The first example that springs to mind is coreutils which used to be textutils, shellutils, and fileutils. Each of those packages contained many programs and could conceivably have been split. Some of the utilities in that package are replaced for most use, for example no-one uses the cksum utility, generally md5sum and sha1sum (which are in the same package) are used instead. Also the pinky command probably isn’t even known by most users who use finger instead (apart from newer Unix users who don’t even know what finger is). So in spite of the potential benefit of splitting the package (or maintaining the previous split) it was decided that it would be easier for everyone to have a single package. The merge of the three packages was performed upstream, but there was nothing preventing the Debian package maintainer from splitting the package – apart from the inconvenience to everyone. The coreutils package in Etch takes 10M of disk space when installed, as it’s almost impossible to buy a new hard drive smaller than 80G that doesn’t seem to be a problem for most users.
The second example is the X server which has separate packages for each video card. One thing to keep in mind about the X server is that the video drivers don’t change often. While it is quite possible to remove a hard drive from one machine and install it in another, or duplicate a hard drive to save the effort of a re-install (I have done both many times) they are not common operations in the life of a system. Of course when you do require such an update you need to first install the correct package (out of about 60 choices), which can be a challenge. I suspect that most Debian systems have all the video driver packages installed (along with drivers for wacom tablets and other hardware devices that might be used) as that appears to be the default. So it seems likely that a significant portion of the users have all the packages installed and therefore get no benefit from the split package.
Now let’s consider the disk space use of the selinux-policy-default package – it’s 24M when installed. Of that 4.9M is in the base.pp file (the core part of the policy which is required), then there’s 848K for the X server (which is going to be loaded on all Debian systems that have X clients installed – due to an issue with /tmp/.ICE-unix labelling [2]). Then there’s 784K for the Postfix policy (which is larger than it needs to be – I’ve been planning to fix this for the past four years or so) and 696K for the SSH policy (used by almost everyone). The next largest is 592K for the Unconfined policy, the number of people who choose not to use this will be small, and as it’s enabled by default it seems impractical to provide a way of removing it.
One possibility for splitting the policy is to create a separate package of modules used for the less common daemons and services, if modules for INN, Cyrus, distcc, ipsec, kerberos, ktalk, nis, PCMCIA, pcscd, RADIUS, rshd, SASL, and UUCP were in a separate package then that would reduce the installed size of the main package by 1.9M while providing no change in functionality to the majority of users.
One thing to keep in mind is that each package at a minimum will have a changelog and a copyright file (residing in a separate directory under /usr/share/doc) and three files as part of the dpkg data store, each of which takes up at least one allocation unit on disk (usually 4K). So adding one extra package will add at least 24K of disk space to every system that installs it (or 32K if the package has postinst and postrm scripts). This is actually a highly optimal case, the current policy packages (selinux-policy-default and selinux-policy-mls) each take 72K of disk space for their doc directory.
One of my SE Linux server sytems (randomly selected) has 23 policy modules installed, if they were in separate packages there would be a minimum of 552K of disk space used by packaging, 736K if there were postinst and postrm scripts, and as much as 2M if the doc directory for each package was similar to the current doc directories). As the system in question needs 5796K of policy modules, the 2M of overhead would make it approach 8M of disk space. So it would only be a saving of 16M over the current situation. While saving that amount of disk space is a good thing, I think that when balanced against the usability issues it’s not worth-while.
Currently the SE Linux policy packages will determine what applications are installed and automatically load policy packages to match. I don’t believe that it’s possible to have a package post-inst script install other packages (and if it is possible I don’t think it’s desirable). Therefore to have separate packages would make a significant difference to the ease of use, it seems that the best way to manage it would be to have the core policy package include a script to install the other packages.
Finally there’s the issue of when you recognise the need for a policy module. It’s not uncommon for me to do some work for a client while on a train, bus, or plane journey. I will grab packages needed to simulate a configuration that the client desires and then work out how to get it going correctly while on the journey. While it would not be a problem for me (I always have the SE Linux policy source and all packages on hand) I expect that many people who have similar needs might find themself a long way from net access without the policy package that they need to do their work. Sure such people could do their work in permissive mode, but that would encourage them to deploy in permissive mode too and thus defeat the goals of the SE Linux project (in terms of having wide-spread adoption).
My next post on this topic will cover the issue of custom policy.
Updated to note that Caleb is a contributor to Ubuntu not a developer.
“as it’s almost impossible to buy a new hard drive smaller than 80G that doesn’t seem to be a problem for most users.”
…then again, my Router is running Debian on a 2GB Compact Flash card. Please keep in mind that the “Universal Operating System” should run on more than just desktop computers with 3.5″ hard drives.
Michael: True. But then there’s nothing stopping you from writing a little script that rm’s things you don’t need after package installation. You could run “rm -rf /usr/share/doc/*” without stopping your machine from operating.
Also the policy modules under /usr/share/selinux/default are not needed once you have loaded the policy, you could delete them (and delete them again if you upgrade the policy package).
The potential disk usage from splitting the policies out into modules is important, but I think it must be secondary to the security concerns of having a single policy package. The most important gain from splitting the policies out into separate packages is not a space savings, but the ability to accurately control your security policy and maintain a least privilege environment.
“Currently the SE Linux policy packages will determine what applications are installed and automatically load policy packages to match.”
Which part of the install does this?
Rather than splitting out the policies into separate packages, why not ship them in the packages that they apply to?
Caleb Case is not an Ubuntu developer. He did some SE Linux package work that was sponsored into Ubuntu during a period with SE Linux in Debian was dormant, but since then we’ve rebased everything on Debian’s packages.
Caleb: The postinst in the Debian packages does this. Look for the population of %map at about line 65.
Also I disagree with your claim about security and will cover it in my next post.
Anon: That would never work, I’ll cover it in my next post.
Scott: I’ve updated the post to describe Caleb as a contributer. Is that correct?
I think that’s not an unreasonable characterization.
@etbe: WRT embedded systems: that’s a really stupid argument, isn’t it? (So bad I thought about adding an expletive.) Yes, you could run a whole load of custom scripts to set up a common environment, but that would completely obliterate the point of a having distribution. Muppet.
Matthew: I’m not sure if you are saying that my suggestion for working around the problem was bad or Michael’s request for having it work on such a machine was a bad idea.
http://doc.coker.com.au/papers/porting-se-linux-hand-held-devices/
For reference in the past I’ve got SE Linux working on a machine with 64M of storage (see the above URL). I did this by building the policy on another machine and copying the image to the target machine. I think that is the best way to deal with really small machines.
The issue is what areas I can spend time working on. I can’t fix all bugs or tune the system for the desires of all users.
Incidentally I run a bunch of Xen virtual machines with small amounts of storage. The machine which hosts my blog has 3G of disk space assigned to it of which 1.4G is free. A router would need significantly less storage space (unless you want to have a Squid cache on the CF).
[…] Comments etbe on SE Linux Policy Packaging for a DistributionMatthew W. S. Bell on SE Linux Policy Packaging for a DistributionScott Kitterman on SE Linux Policy […]