Re: [RFC] CIL and Source Policy Integration

[Daniel J Walsh <dwalsh@redhat.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> 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.
> 
> 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.
> 
> - Steve _______________________________________________ Selinux mailing
> list Selinux@tycho.nsa.gov To unsubscribe, send email to
> Selinux-leave@tycho.nsa.gov. To get help, send an email containing "help"
> to Selinux-request@tycho.nsa.gov.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLPCsUACgkQrlYvE4MpobNWmwCfTNOaPPIpnGX+yIVkffNhDJ6L
QQkAmgPt3w7LoRo/q0D0FmWLCTkz+mDN
=wjQm
-----END PGP SIGNATURE-----