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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux