On 01/09/2014 11:56 AM, Steve Lawrence wrote:
On 01/09/2014 11:15 AM, Stephen Smalley wrote:
On 01/08/2014 03:44 PM, Steve Lawrence wrote:
src-revert:
Reverts changes made to master that conflict with the src-policy
branch (e.g. how paths are handled, enabled/disable modules). Rather
than dealing with a large amount of conflicts, it was easier to just
remove the commits which add conflicting features, rebase the old
source policy work on top of that, and add back any features that in
manner consistent with source policy. This also reverts the preserve
tunables patchset, but as I look at it while typing this, I realize
that was unnecessary. Aside from numerous conflicts and the need to
add CIL support, the only real issue is that the preserve tunables
feature uses the -P flag, which source policy uses for priority. So I
guess we'll have to pick a different letter.
Obviously we'll need that support as it is used.
Agreed
integration:
This branch builds CIL into libsepol, and updates libsepol,
libsemanage, semodule, and semanage to work with and understand only
CIL files. Switching to CIL has a few side effects, such as removing
base modules, versions, upgrades, adding configuration options to
semanage.conf, etc. This also removes support for binary .pp modules.
So what's the transition plan for distributions with existing binary .pp
modules, some of which will be locally generated by users?
This is a tricky problem. A few ways I've thought (there's probably some
more, I'm all ears):
1) Add high level language support, treat .pp files as a higher level
language, and create a pp to cil converter. I think reversing .pp files
was looked at in the past (I forget who or where it ended up), though
I'm not sure how easy it would be translate a .pp to .cil. This would
probably be ideal and would minimize the transition pain, but the
difficulty of converting pp to cil is unknown to me.
A pp to cil converter should not be too hard in general, since all the m4 stuff
has been expanded. But it would be better to convert from source.
2) Similar to 1, add high level language support, but have distributions
switch over to using source refpolicy, and have a te/if/fc to cil
converter. This would be nice in that distros could still work off of
the familiar refpolicy. The downsides are this doesn't solve the problem
of users with custom .pp modules, and as Jim has found out, converting
from source refpolicy to cil is not an easy process, and requires some
manual intervention. It's possible we could start massaging refpolicy
into something that is easier to automatically convert to cil, but I
don't know what would be needed.
I don't think the distro policy presents too much of a problem. Conversion
requires patching the old refpolicy tree in a few places (maybe more for
Fedora's policy), but once the conversion is done, both Refpolicy packages and
CIL source can be generated from the same policy without any manual intervention.
There have already been some patches made to Refpolicy to make it easier to
convert to CIL and I am willing to generate new patches. I have also done some
work on Fedora's policy to see what is needed to convert it to CIL, but have
been spending more time on the CIL compiler recently.
Converting the module source is easy if the rest of the policy is around in a
form that can be converted to CIL. It shouldn't be too hard to make a tool that
can read in a CIL policy and a Refpolicy source module and output a CIL source
module and I plan on doing that.
3) Add a configuration option (semanage.conf?) which specifies which
format the module store is in (pp vs cil). Userspace always supports
both, but only one at a time. The downside of this is we have to
maintain two separate policy types. We could eventually deprecate .pp
support, but it might take a while before everyone switches over to cil
to the point where we could deprecate.
We probably need to do this regardless, don't we?
--
James Carter <jwcart2@xxxxxxxxxxxxx>
National Security Agency
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
