Re: [RFC] CIL and Source Policy Integration

[James Carter <jwcart2@tycho.nsa.gov>]

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@tycho.nsa.gov>
National Security Agency