On 02/12/2015 11:00 AM, Stephen Smalley wrote: > On 02/12/2015 10:43 AM, Richard Haines wrote: >> >> >> Would now be a good time to consider moving the Android policy to support CIL >> as aosp and seandroid have the CIL compiler installed (external/libsepol/cil >> - the >> cil/docs/Makefile will generate a CIL reference guide). >> >> In the long term it may help alleviate some of these problems. >> >> Detailed information on the CIL design can be found at: >> https://github.com/SELinuxProject/cil/wiki >> (Note this is a bit dated and not all features are available yet (e.g. type >> inheritance), >> however the CIL ref guide lists all current features). >> >> >> Example CIL policy for the emulator and flo devices can be found at: >> >> http://taiga.selinuxproject.org/~rhaines/Android/aosp_cil_sepolicy-1138.tar.gz >> (only the emulator has been tested) > > I enabled the libsepol CIL support and secilc in the AOSP build with the > intent of ultimately leveraging CIL to optimize the Android policy, see > the second bullet of: > https://bitbucket.org/seandroid/wiki/wiki/ToDo > > That is just looking at automatically converting Android policy to CIL > and running it through secilc at build time to pick up the benefits of > automatic attribute generation for type negations and removal of unused > attributes. It is not looking to replace the Android policy sources > with a CIL rewrite. > > I think the latter would be a tough sell for Android. Especially as > three major versions (4.3, 4.4, and 5.0) have now gone out with SELinux > enabled and therefore OEMs have already had to deal with writing > device-specific policies and learn the existing syntax. Plus there are > already tools elsewhere in Android that parse policy.conf syntax, > particularly for neverallow checking of device policies. And I know of > OEMs who have their own internal tools that parse source policy for > various purposes. > > If/when someone creates a real HLL for SELinux, we might be able to > justify moving to the HLL based on making life simpler for policy > writers. But I can't quite see that for switching to CIL as the source > language. It doesn't seem easier for humans, and that isn't surprising > as that wasn't its purpose. > > I did look briefly at your earlier CIL policy when you released it. > However, as you did it as a manual rewrite to fully leverage CIL, there > is no way to be confident that it is fully equivalent (can't sediff it). > Also, since you renamed the domains and types to leverage CIL namespace > features, I'd have concerns about the implications for compatibility for > upgrading existing devices and for retraining OEMs in the new naming > conventions. Certainly one could use typealiases to preserve backward > compatibility but those are generally frowned upon in Android policy and > it would be a complete renaming. I don't know if your updated CIL > policy is the same way or not - haven't looked yet.
The other issue with the namespacing is storage cost - every file context just got longer. And it doesn't appear to offer any real benefit, at least for Android; the type names already include an indication of the kind of object. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
