SELinux Build

Building SELinux and integrating it into the OpenXT predecessor's build system isn't a simple task. Our recent push to separate the XT specific policy from the core reference policy isn't going to make this any less complex. This page will track my efforts to do just this. In the process I'll document our current approach and my proposed changes. This is mostly to get input from zh and other concerned parties.

Justification

Before getting into the details it's probably a good idea to justify all of the effort that's going into this. Most of this can be summed up into one word: maintainability (I may have just made this word up).

Our current SELinux policy is a fork of a ~4 year old refpolicy release. We've made significant changes both to the base policy and in a number of policy modules that are specific to XT. Back when XT started I don't think anyone realized it would still be around 4 years later. With some very constrained initial time constraints we just kept lumping policy on top of the refpolicy release we started.

SELinux has a pretty good (though imperfect) system for dealing with extending the base policy in a relatively structured way though and we didn't capitalize on this. Now we're faced with either continual misery at the hands of rebasing our policy on a more recent upstream release or temporary misery re-structuring our build and packaging approach to make upgrades to the base policy less miserable in the future.

I've opted for the later as it will make the task of maintaining the SELinux policy more approachable for someone other than myself in the future.

Current Method

Since all of the XT specific policy (changes to refpol and XT modules) are directly in the policy sources the policy currently is built (mostly) in one step. All of this is contained in the selinux-policy_git recipe in xenclient-oe.git. Building the policy is pretty straight forward. This is done using the refpolicy Makefile.

The install task is where most of the interesting stuff happens. This is where the policy modules are compressed, copied into the right place and all of the modules are linked to produce the final binary policy. Further the policy headers are installed as well. The headers eventually land in the sysroot. This is to allow other modules to build against the interfaces provided by the refpolicy. Currently we don't take advantage of this possibility but we will soon hopefully.

Finally the package postinstall hooks are used to relabel the file system when the package is installed. This is how we set the initial file contexts in the XT rootfs'. This last bit requires cooperation from the xattr extensions we've added to pseudo and the file system utilities (the patches for these need to go upstream badly).

Proposed Changes

This section documents the roadmap / plan for migrating the XT SELinux bits over to the latest refpolicy provided by the upstream meta-selinux layer.

Integrate meta-selinux

Status: completed

This step is intended to get rid of the SELinux recipes we created for bitbake in XT. The upstream meta-selinux layer make our recipes redundant.

Extract XT Modules

Status: in progress

In this step we will keep the existing fork of the refpol (including our changes) but will migrate to building the XT policy modules in a separate recipe and source tree.This will complicate:

1) linking the policy

2) labeling the root file system

Currently our policy recipe as well as the refpolicy from meta-selinux link the policy in the install step and package it. When we move the XT modules out into a separate recipe we won't be able to do this any longer. My current plan move the policy linking step into an image post processing step. This will allow all of the modules to be built before the link step. Specifically this will allow policy modules to be built in recipes separate from the reference policy recipe.The file system labeling isn't completely consistent. The NDVM fs is labeled in the image recipe while dom0 is not. The dom0 FS is still an unlabled archive (according to ZH). So long as file system labeling is done after the policy modules are linked everything should work. Eventually we should try to make the FS labeling consistent but since it works currently and I don't expect these changes will disrupt the current approach I'm going to leave it alone.

De-fork

Status: pending

This is by far the most painful of the steps in this process and will thusly be saved for last. Here we need to find the XT specific stuff in our policy fork and pry it out into a patch queue. This would then be applied on top of the meta-selinux policy. This will allow us to build the XT policy modules against the meta-selinux policy. I've already exeprimented with setting up a patche queue which was simple enough. It's up