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? Is there an option to discard the .pp files altogether and only retain the cil files? _______________________________________________ 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.
