Binary policy modules

[Stephen Smalley]

On Wed, 2005-10-12 at 19:14 +0100, Mike Hearn wrote:
> Hmm, I don't quite understand - my intention was to ship a binary policy
> module installed when the package manager is first installed, which then
> defines a new domain almost_but_not_quite_root (with a better name of
> course ;). Packages/installers would then be run in this domain instead of
> being unconfined.

Ok, that can be done without the policy server.

> Why does this need access control on the policy itself? Or do you mean,
> that in FC5 it won't actually be possible to install third party
> policy modules?

No, that should be possible.  What I meant was the ability to confine
the rules that can exist in a given policy module installed from a given
package, e.g. so that a policy module shipped in the foo package can't
open up read access to /etc/shadow.  That requires the policy server,
see
http://sepolicy-server.sourceforge.net/index.php

However, the good news is that the module infrastructure has been
developed with this in mind, so whether or not a module install is
performed directly on the module store by libsemanage or sent off to the
policy server for handling is hidden behind the libsemanage interface,
and the user programs like semodule use that interface.  Switching over
to the policy server just requires altering a config file for
libsemanage.

-- 
Stephen Smalley
National Security Agency