On 07/17/2014 04:37 PM, Stephen Smalley wrote: > 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. > > BTW Moving the policy out of /etc is also great. I would like to see policy loaded from /var/lib/selinux/ if it exists and then look in /usr/lib/selinux/ if it does not. Then distributions could ship their own policies, and if a user wanted to get back to Factory install he could just rm -rf /var/lib/selinux _______________________________________________ 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.
