Re: [RFC] Source Policy, CIL, and High Level Languages

[Steve Lawrence <slawrence@tresys.com>]

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?
> 

Yep. The only features reverted were enable/disable and
semanage_set_root (multiple commits added these features, which is why
there are 8 commits). Enable/disable as added back by the source policy
work, and setmanage_set_root was manually added back.

>>> 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?

Yes. The changes to semodule were:

New option -X, --priority to set the priority, defaults to 400.
New option -C, --ignore_module_cache to ignore cached CIL modules to
force recompilation.
Deprecated --base and --upgrade, which are both equivalent to --install.
Versions are no longer output in semodule --list (they don't exist in CIL).
The -l option can now accept a parameter (either "full" or "standard").
"standard" lists just active modules. This is the default if a parameter
is not provided. "full" lists all modules, priorities, and high level
language.

Changes to semanage:
- Add support for priorities with the module subcommand with the -X option
- Removes version references
- Modifies list to also output priority and hll
- Making a module permissive uses CIL instead of building a pp module



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