Binary policy modules

[Joshua Brindle]

Mike Hearn wrote:
> 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?
> 
I am dubious about this but in reality it isn't necessary to keep the 
module around at all so it isn't dangerous storing them in $HOME or 
anywhere else, so long as we are controlling access to the module store 
(coarse grained access via direct semanage and fine grained via policy 
management server)

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

> thanks -mike
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>