Binary policy modules

[Mike Hearn]

On Thu, 13 Oct 2005 11:33:05 -0400, Joshua Brindle wrote:
> Ok, my answer was about the module format. The module format is versioned
> so that older policies will work with newer selinux systems, but vice
> versa isn't automatic, the module would need to be downgraded (there is a
> similar discussion to this on the selinux list currently)

Hmm, OK. As long as it's possible to generate the policy files on a
standard desktop system then this is an OK tradeoff, though for efficiency
reasons one backwards/forwards compatible file would be the best. 

What I'd really like to avoid is the sillyness we are in with header files
and symbol versions, where you need obscure tricks to build on newer and
run on older (or just do it in a VM). Having to use a VM to build portable
policy wouldn't be much fun.

> in all of the mentioned policies types and attributes may or may not be
> present and may have different meanings; filesystem labels may also be
> different. modules have the ability to enable policy based on the presence
> of symbols (types, attributes, etc) and this may help some but probably
> not entirely.

It would be nice if there were some standards on how to identify
particular vendor policy, eg:

optional {
   require { fedora_targeted_t }
   
   # fedora specific stuff goes here
}

optional {
   require { gentoo_policy_t }

   # gentoo specific stuff goes here
}

But a unified policy would be the best solution. I hope Red Hat support
the reference policy effort.

> I think it is relavent because there are important concepts, proper
> integration with a package manager means several things:
> 
> The modules must be associated with the packages someway (I suggest
> dependancies)

Why not simply include the policy inside the package? Remember the use
case for autopackage - a non-technical user goes to the SuperTux website
and clicks the "Install SuperTux" button, Firefox downloads and opens the
autopackage and the software installs. On any distro. I don't see why
separating policy into a separate package here would be beneficial
(though it could be done, AP supports dep resolution).

> The package manager must apply policy before installing an application, so
> that labeling will work correctly

This can certainly be done.

> The package manager should install policy modules to a directory it 'owns'
> such as /usr/lib/selinux and then use libsemanage (semodule) to add
> modules.

If policy can go anywhere, I'd really like to see a standard directory
like there is for .desktop files. If policy can be installed without root
in a user-specific manner in future, then having a standard location in
$HOME for it would be good.

You said they were architecture-independent, so /usr/share/policy and
$HOME/.config/policy (~/.config is a freedesktop.or thing) would seem
sensible.

> The package manager should understand how policy transactions work,
> conflicting modules that must be removed/added within the same transaction
> (such targeted and strict variations of the same policy)

Can we have more information on this? Presumably for an upstream provided
package, the answer is simply to uninstall the relevant RPM if present and
install the new package - of course if policy is in a separate package
then the old policy would still be lying around in this case.

What happens if two policy modules define conflicting policy? Is it
possible to find this out before install time?

> It should also fetch and install policy modules before installing a chain
> of applications, this way the policy isn't rebuilt/reloaded between every
> app that has a policy, which can lead to inconsistancies or worse, races.

That's not too hard for us to do.

thanks -mike