Binary policy modules

[Joshua Brindle]

Mike Hearn wrote:
> 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.
> 
This is an interesting issue that I hadn't been thinking about..

> 
>>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.
> 
we've talked about decorative types before, it's not that elegant but it 
would probably work. It doesn't address version issues though, if you 
watch the rawhide policy development you'll see alot happening, policy 
version specific dependencies are going to be a problem I think.

> 
>>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.
> 
There should never be home or user based policies so they should go to a 
system location. It doesn't matter to me, so long as the package manager 
doesn't try mucking around in the module store directly.

> 
>>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.
> 
uninstalling the policy RPM won't remove it from the policy. Since the 
module installed to the system (/usr/share/selinux/policy or whatever) 
it will be removed but the one in the module store (not owned by RPM) 
wouldn't be. The RPM could probably use semodule to remove it as part of 
the uninstallation phase though. The AP packages also need to be able to 
handle this.

However, say you are changing modules, you shouldn't uninstall one and 
then install the other in seperate transactions because the applications 
labels will become invalid (file and process). Of course the install of 
the new module should try to relabel affected files, but you'd have 
process labels invalidated in the process. The correct way is to start a 
transaction, remove the old module, add the new one and commit. If the 
type names change you'd have to shut down the application beforehand and 
relabel the files afterward.

> What happens if two policy modules define conflicting policy? Is it
> possible to find this out before install time?
>
They won't link so you'll get an error when you try to commit the 
transaction.

> 
>>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.
> 
This is the main reason I think seperate policy packages are better, if 
you are able to take all the pending packages, do the policy installs 
upfront and then the package installs it would be fine to package them 
together but the idea of doing 2 phase installs of a set of packages 
seems awkward.