Re: [RFC] CIL and Source Policy Integration

[Stephen Smalley <sds@tycho.nsa.gov>]

On 01/09/2014 03:47 PM, Daniel J Walsh wrote:
> 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.
> 
> It has got to be this one.  Remember you also have a huge amount of "google"
> knowledge out there.  People will be writing pp files for a while.

Yes, I agree.  semodule_unpackage and checkpolicy/test/dismod should get
you part of the way there, but you'll have to turn dismod into a full
featured disassembler for binary modules and have it generate cil.
We have to assume that people will have .pp files for which they no
longer have source, especially audit2allow -M generated ones.