SELinux Module Packaging in FC5

[Paul Howarth]

On Fri, 2006-05-19 at 09:12 -0400, Stephen Smalley wrote:
> On Thu, 2006-05-18 at 14:18 +0100, Paul Howarth wrote:
> > Another query regarding policy module packages in RPMs:
> > 
> > Supposing a package is installed when the system has SELinux disabled.
> > 
> > What would happen if semodule was called to install a policy module?
> > 
> > If the result is that nothing happens (or semodule bombs out with an 
> > error of some sort), what would then happen if the system subsequently 
> > had SELinux enabled and the system was relabelled? Would the package 
> > containing the policy module have to be reinstalled?
> > 
> > I'd try it myself but I can't bring myself to disable SELinux on any of 
> > my boxes and go through the whole relabelling process.
> 
> If policy is installed on the system, then semodule (actually
> libsemanage) will install the module and rebuild the generated files,
> but will not try to load policy into the kernel since SELinux is
> disabled.  Then, if you enable SELinux, the module will already be
> included in the policy.
> 
> If policy is not installed on the system, then semodule will abort with
> an error like this:
> semodule:  SELinux policy is not managed or store cannot be accessed.
> 
> Note also that one should generally use semodule -s <policytype> as in
> the selinux-policy .spec file to indicate which kind of policy your
> module is built for (targeted, strict, mls).  Then, if the system is
> running a different kind of policy, semodule will know to install the
> module to the proper location (not the active policy) and to not try to
> load it.

OK, this leads on to some other issues:

Ideally, I'd like to be able to package up policy modules built for each
of the base policies that are shipped in Core. The Makefile currently
defaults to targeted policy - how should modules for other base policies
be built, particularly in the mock environment used for the Extras build
system, where SELinux is disabled.

Following on from that, at package install-time it would be necessary to
identify which base policy/policies is/are installed, and install the
appropriate modules. Is there a convenient way of finding out which
policy/policies are installed without doing an rpm query?

There's also the awkward problem of what to do if a base policy is
installed at a later date than a package containing a policy module. For
instance, someone might decide to try out the strict policy. Any package
containing policy modules for the strict policy would already have
skipped its chance to install the strict module during its %post. This
could be addressed using triggers but the complexity that would involve
for handling all possible policies would make it a struggle to get it
past a package review :-) Perhaps an alternative would be for packages
to have some way of registering the modules they have available for each
base policy, so that they were automatically picked up if that base
policy was installed?

Paul.