On 07/17/2014 04:04 PM, Steve Lawrence wrote: > On 07/17/2014 03:48 PM, Stephen Smalley wrote: >> On 07/17/2014 03:10 PM, Stephen Smalley wrote: >>> On 07/17/2014 02:58 PM, Steve Lawrence wrote: >>>> I think the only remaining issue is the one Dominick mentioned in his >>>> first email regarding file_contexts.homedirs. I don't think this is an >>>> actual bug, just the migration script migrating things that don't need >>>> to be migrated. Still investigating it. We should have an update >>>> sometime tomorrow. >>> >>> So everything you reverted you restored in equivalent form? >>> >>>>> What new functionality is included here that was not previously >>>>> supported by the old policy toolchain? >>>> >>>> In terms a user would see, the most visible change is support for CIL >>>> policies and HLLs, of which there's only one right now (pp2cil). There >>>> are also some new semanage.conf options (target-platform, compiler-dir, >>>> ignore-module-cache, store-root) but I imagine the vast majority of >>>> people could just use the defaults. Similarly, we've added >>>> --ignore-module-cache and --store-root to the semodule command. We've >>>> also moved the store to /var/lib/selinux, but this is more behind the >>>> scenes and should really only affect distributions. >>> >>> What about new features/options of the user-facing commands? I know >>> some features were copied from earlier source/CIL releases into the main >>> selinux userspace (e.g. enabled/disabled modules), but aren't some >>> things like module priorities new? >>> >>>> Though, there are two things we just realized have a different behavior. >>>> >>>> 1) verify_modules is now performed on the CIL modules, rather than pp >>>> (or HLL) modules. So if someone is using verify_modules, things will >>>> probably break. I'm not sure if anyone uses this feature or how >>>> important it is that we maintain backwards compatibility. >>>> >>>> 2) verify_linked is no longer called, since there isn't any concept of a >>>> linked base module with CIL >>>> >>>> Aside from that, I think all functionality should remain the same. >>> >>> I'm not aware of anyone using anything other than verify kernel. >>> >>>>> Any chance of getting a hll compiler for refpolicy source modules, i.e. >>>>> in .if/.te/.fc form? >>>> >>>> That's in the plan. Jim has a tool that will compile .if/.te/.fc to CIL, >>>> but the current HLL infrastructure may need some changes before that can >>>> be supported. I think the main problem is that Jim's tool needs >>>> knowledge of all modules to be able to convert them to CIL, but the >>>> current HLL infrastructure compiles each module separately. We have >>>> various ideas on how we can update the HLL infrastructure to support >>>> this, but we've primarily been focused on getting the core CIL/HLL >>>> functionality complete and upstreamed before focusing on the more >>>> complicated HLL patterns. >>> >>> Ok. Ultimately audit2allow -M i.e. sepolgen module compiler should be >>> re-tooled to generate source modules, and we'll essentially need a >>> workflow that replaces the old make -f /usr/share/selinux/devel/Makefile >>> mymodule.pp; semodule -i mymodule.pp. >> >> I guess one other possible concern might be storage: >> >> $ du -sh /etc/selinux/targeted/modules /var/lib/selinux/ >> 5.4M /etc/selinux/targeted/modules >> 11M /var/lib/selinux/ >> >> I'm guessing that is just the cost of storing each module in both binary >> and cil form? > > Yep, we store both HLL and CIL. They are both compressed and CIL > compresses decently since it's just text, but it's still a lot of text. > >> Is there an option to discard the .pp files altogether and only retain >> the cil files? > > Not at the moment, but it wouldn't be hard to accomplish. Just need to > delete all the hll files and change the contents of lang_ext to 'cil'. > Something we could add if storage is an issue. That worked, albeit I had to learn that lang_ext must not include a newline or libsemanage won't accept it. Took it down to 5.8M. I suspect we could also stop retaining a copy of certain generated files like file_contexts although that is no different than the current code. Not sure what benefit there is in retaining the pp files, since they carry no additional information AFAIK and they aren't human viewable or editable. Is there even an option for exporting modules from the policy store currently that would allow extracting them except via direct file access to the policy store? More generally, if the user knows that the hll module is going to be saved elsewhere, then there is no reason to retain a copy in the policy store, so having the option of dropping the hll version, either for all modules or for specific modules, seems useful. _______________________________________________ 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.
