On 01/09/2014 01:34 PM, James Carter 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. >> > > 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? > It's probably a good idea, but I don't think it's necessary in all cases. As long as we also add support for converting .pp files to .cil (like in 1), once you install the new userspace it could just consider all existing .pp files as an HLL and convert them to CIL when building a new policy. If we had a transition plan that did not include the ability to convert pp files, then yes, we would definitely need it configurable. - Steve _______________________________________________ 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.
