Binary policy modules

[Stephen Smalley]

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