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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
