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. _______________________________________________ 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.
