Mike Hearn wrote:
On Wed, 12 Oct 2005 15:37:35 -0400, Joshua Brindle wrote:
The format is versioned the same way the kernel binary format is, so any
changes to the format use a different version number, and backward
compatbility is retained.
That's good, but it's not what I asked. What are the binary compatibility
commitments you guys are making? Is it expected that the format will
change in future? Was it designed to be extendable? Is there some kind of
internal chunking system so new data can be added in a way that older
versions of SELinux will ignore?
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)
however, the package itself isn't versioned, if the format is changed
older systems may not be able to cope with it. This is something we need
to look at.
only as neutral as policies are, which isn't all that neutral right now.
Hmm, that sucks. For very simple policy like "this process can do XYZ"
shouldn't it be independent of targeted vs strict/fedora vs gentoo?
Are the capability names actually variable between distributions?
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.
Hopefully this will change when reference policy is used by everyone
and optional tunables are built in to the language.
OK, I'm glad there's a plan for this.
you might look at this thread:
http://marc.theaimsgroup.com/?l=selinux&m=112871525005860&w=2 for more
information. Particularly the justification for building seperate packages
for policy and the application.
OK. This doesn't affect autopackage so much as it's meant for third party
packages, and therefore developers are expected to define their own policy
which would be independent of strict/targeted. I question the solution
given for RPM - why not simply fix RPM so it loads policy before
installing files?
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)
The package manager must apply policy before installing an application,
so that labeling will work correctly
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.
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)
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.
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
