Binary policy modules

[Mike Hearn]

On Thu, 13 Oct 2005 14:00:54 -0400, Joshua Brindle wrote:
> 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.

Why not home/user based policies? If the user can install software to
$HOME (and they can), why not policy too? If the meta-policy stuff works
out then you should be able to impose extra restrictions/add extra rules,
but not reduce the security of the system surely?

> 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.

OK.

> 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.

Does semodule let you do this kind of atomic exchange?

thanks -mike