On Thu, 2005-10-13 at 14:55 +0100, 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?
Good questions; I don't think that this has been fully resolved.
MLS compatibility is also an issue; Fedora has enabled MLS/MCS, whereas
other distros have not yet done so, and the format is affected by that.
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?
Not the "capability names" i.e. class/permission names, but the
domain/type names can vary. To the extent that the distributions use a
common baseline for their policies, such variations should be minimal,
and the reference policy will help in that respect going forward as
well. To date, the NSA example policy has served that purpose, but not
all distros have followed it. In the strict vs. targeted case, you have
the issue that not all domains/types defined in the strict policy have
equivalents in the targeted policy (since strict policy confines more
processes and provides finer-grained distinctions), but that can largely
be addressed via type aliases in the targeted policy so that you can
refer to the strict policy type names regardless.
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?
Yes, I agree with that. One potential issue is with installing a large
number of packages; you'd like to be able to batch up all of the policy
modules into a single policy update and load, and then unpack all of the
packages.
--
Stephen Smalley
National Security Agency