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