[RFC] CIL and Source Policy Integration

[RFC] CIL and Source Policy Integration

[Steve Lawrence]

As has been posted to this list before in the past, we have made a lot
of progress with CIL [1]. Although we are still making changes, we are
now capable of building SELinux binary policies from CIL versions of
refpolicy and SEAndroid policy. A related project that we are working
on, and the purpose of this RFC, is to modify SELinux userspace to
include the CIL and the Source Policy work completed a few years ago.
We have completed a preliminary integration, so we are sending out this
RFC to start discussions and ask questions. To start it off, what is in
the way of getting these branches merged into master, and how can we
help mitigate that? Are the any changes that you question? Can we find
a work around?

Instead of sending the patchset to this list (54 commits, 4000
insertions, 2000 deletions), all the changes are pushed to the selinux
git repository to the following three branches, each one building on the
other. The branches and their purpose is described below:

src-revert:
   Reverts changes made to master that conflict with the src-policy
   branch (e.g. how paths are handled, enabled/disable modules). Rather
   than dealing with a large amount of conflicts, it was easier to just
   remove the commits which add conflicting features, rebase the old
   source policy work on top of that, and add back any features that in
   manner consistent with source policy. This also reverts the preserve
   tunables patchset, but as I look at it while typing this, I realize
   that was unnecessary. Aside from numerous conflicts and the need to
   add CIL support, the only real issue is that the preserve tunables
   feature uses the -P flag, which source policy uses for priority. So I
   guess we'll have to pick a different letter.

src-policy:
   This is a rebase of the old src-policy branch onto the src-revert
   branch. The goal of this patchset is to improve the API for module
   handling, as well as support source policies, module priorities,
   better enabling/disabling of modules, and moving the policy store
   from /etc/selinux/<store>/modules to /var/lib/selinux/<store>/.

integration:
   This branch builds CIL into libsepol, and updates libsepol,
   libsemanage, semodule, and semanage to work with and understand only
   CIL files.  Switching to CIL has a few side effects, such as removing
   base modules, versions, upgrades, adding configuration options to
   semanage.conf, etc. This also removes support for binary .pp modules.

With these three branches, it is possible to build and manage SELinux
policy using CIL files and the familiar semodule/semanage tools.

To make this easier for the community to play around with, we have
created a VMWare virtual machine [2] that has all the necessary setup to
start using SELinux userspace tools with CIL, including the installation
of the CIL refpolicy created by Jim (for a quick test, run semodule
-lfull). If you would rather build this yourself, the steps are at the
bottom of this email.

Thanks, and we look forward to receive your feedback.

- Steve

[1] http://userspace.selinuxproject.org/trac/wiki/CilDesign
[2] http://oss.tresys.com/files/cil/CILTest_Fedora_19_x86_64.tar.bz2



Steps to Install SELinux Userspace with CIL Integration and Full CIL
RefPolicy

# Start with a Fedora 19-x86_64 Minimal Installation

# install userspace selinux dependencies
$ yum install pcre-devel ustr-devel bzip2-devel audit-libs-devel flex
flex-static python-devel setools-devel libcgroup-devel libcap-ng-devel
glib2-devel dbus-devel dbus-glib-devel swig libsepol-static python-IPy

# put the system into permissive mode
$ sed -ri 's/(^SELINUX=).*/\1permissive/' /etc/selinux/config
$ setenforce 0

# clone the repos and checkout branches
$ git clone -b integration http://oss.tresys.com/git/selinux.git
$ git clone https://bitbucket.org/jwcarter/secilc.git
$ git clone -b old_syntax https://bitbucket.org/jwcarter/cilpolicy.git

# create a symlink to secilc so cil can be built into libsepol
$ ln -s ~/secilc/ selinux/libsepol/cil

# install selinux userspace with cil integration
$ make -C selinux LIBDIR=/usr/lib64 SHLIBDIR=/lib64 install install-pywrap

# create the new module store
$ mkdir -p /var/lib/selinux/cil-test/active/modules

# copy the targeted configuration to cil-test (not valid for the policy, but
# needed for bootable system)
$ mkdir -p /etc/selinux/cil-test/policy
$ cp -r /etc/selinux/targeted/{contexts,seusers,setrans.conf}
/etc/selinux/cil-test/

# set the store to cil-test
$ sed -ri 's/(^SELINUXTYPE=).*/\1cil-test/' /etc/selinux/config

# install all the CIL policies
$ cd cilpolicy
$ xargs -a LISTING semodule -i

Re: [RFC] CIL and Source Policy Integration

[Dominick Grift]

On Wed, 2014-01-08 at 15:44 -0500, Steve Lawrence wrote:

> Thanks, and we look forward to receive your feedback.

I played with this a bit this morning. Followed all steps.

(it was missing some trivial instructions like install git, gcc and
bison) (no big deal but still might be worth mentioning for others)

You also may want to relabel the file system when all other steps are
done

We are instructed to "cp
-r /etc/selinux/targeted/{contexts,seusers,setrans.conf} /etc/selinux/cil-test/"

Would be nice if we could get rid of the step because it introduces
inconsistency in the policy

One really visible result is that for some reason files that are created
(using a non-mls cilpolicy as per instructions) end up mislabeled
because they are created without the mls attribute (for instance
without :s0). SELinux considers those invalid (unlabeled) even though it
is non-mls policy. The contexts we had to copy
from /etc/selinux/targeted are valid because existing objects (with :s0)
are fine. The problem is the objects that creating in a running system.

I will keep tinkering

Re: [RFC] CIL and Source Policy Integration

[Dominick Grift]

On Thu, 2014-01-09 at 14:35 +0100, Dominick Grift wrote:
> On Wed, 2014-01-08 at 15:44 -0500, Steve Lawrence wrote:
> 
> > Thanks, and we look forward to receive your feedback.
> 
> I played with this a bit this morning. Followed all steps.

When one runs semodule -B, things start to break because of the login
mappings that disappear, and as a consequence the home dir contexts also
disappear.

It removes the login mappings, and the content of user home directories
end up with type default_t

Most of the issues are due to: "cp
-r /etc/selinux/targeted/{contexts,seusers,setrans.conf} /etc/selinux/cil-test/"

It should work without that step (either that or i am overlooking
things)

Re: [RFC] CIL and Source Policy Integration

[Steve Lawrence]

On 01/09/2014 09:51 AM, Dominick Grift wrote:
> On Thu, 2014-01-09 at 14:35 +0100, Dominick Grift wrote:
>> On Wed, 2014-01-08 at 15:44 -0500, Steve Lawrence wrote:
>>
>>> Thanks, and we look forward to receive your feedback.
>>
>> I played with this a bit this morning. Followed all steps.
> 
> When one runs semodule -B, things start to break because of the login
> mappings that disappear, and as a consequence the home dir contexts also
> disappear.
> 
> It removes the login mappings, and the content of user home directories
> end up with type default_t
> 
> Most of the issues are due to: "cp
> -r /etc/selinux/targeted/{contexts,seusers,setrans.conf} /etc/selinux/cil-test/"
> 
> It should work without that step (either that or i am overlooking
> things)
> 
> 

Considering this patchset really only changes where modules are
installed and the format of those modules, I suspect you're right that
copying the targeted configuration is causing some issues. Plus the fact
that the policy is based on old refpolicy and not fedora policy, I
expected policy related issues. However, the main goal of this RFC was
to determine if the CIL and Source policy integration is headed down the
right path, and determine if there are any high level design flaws or
any issues that need to be worked out for upstream integration to occur.
If the only remaining issue is getting a system working in enforcing, I
think we're okay with that.

We'll continue to look into the issues you described and see if we can
come up with fixes, but I suspect they are more policy/configuration
related, and not problems with the patchset.

Thanks!
- Steve

Re: [RFC] CIL and Source Policy Integration

[Dominick Grift]

On Thu, 2014-01-09 at 10:27 -0500, Steve Lawrence wrote:

> Considering this patchset really only changes where modules are
> installed and the format of those modules, I suspect you're right that
> copying the targeted configuration is causing some issues. Plus the fact
> that the policy is based on old refpolicy and not fedora policy, I
> expected policy related issues. However, the main goal of this RFC was
> to determine if the CIL and Source policy integration is headed down the
> right path, and determine if there are any high level design flaws or
> any issues that need to be worked out for upstream integration to occur.
> If the only remaining issue is getting a system working in enforcing, I
> think we're okay with that.
> 
> We'll continue to look into the issues you described and see if we can
> come up with fixes, but I suspect they are more policy/configuration
> related, and not problems with the patchset.
> 
> Thanks!
> - Steve

Alright, i understand. I do suspect this is more than just a simple
policy issue but i can't narrow it down at the moment. Login mappings
are missing one way or another, and that seems to break other things
like home dir context generation. Since semodule -B initiates all this i
would argue that semodule -B functionality for at least some part is
broken on way or another.

I did do other tests and they seems to all pass.

For example disabling and enabling modules:

so for example:

semodule -d irc (disabled it: confirmed with sesearch)
cd cilpolicy xargs -a LISTING semodule -i
(tells me that it will disable irc module after install because its set
disabled: confirmed with sesearch)
semodule -e irc (enables it again: confirmed with sesearch)

Re: [RFC] CIL and Source Policy Integration

[Steve Lawrence]

On 01/09/2014 11:09 AM, Dominick Grift wrote:
> On Thu, 2014-01-09 at 10:27 -0500, Steve Lawrence wrote:
> 
>> Considering this patchset really only changes where modules are
>> installed and the format of those modules, I suspect you're right that
>> copying the targeted configuration is causing some issues. Plus the fact
>> that the policy is based on old refpolicy and not fedora policy, I
>> expected policy related issues. However, the main goal of this RFC was
>> to determine if the CIL and Source policy integration is headed down the
>> right path, and determine if there are any high level design flaws or
>> any issues that need to be worked out for upstream integration to occur.
>> If the only remaining issue is getting a system working in enforcing, I
>> think we're okay with that.
>>
>> We'll continue to look into the issues you described and see if we can
>> come up with fixes, but I suspect they are more policy/configuration
>> related, and not problems with the patchset.
>>
>> Thanks!
>> - Steve
> 
> Alright, i understand. I do suspect this is more than just a simple
> policy issue but i can't narrow it down at the moment. Login mappings
> are missing one way or another, and that seems to break other things
> like home dir context generation. Since semodule -B initiates all this i
> would argue that semodule -B functionality for at least some part is
> broken on way or another.
> 
> I did do other tests and they seems to all pass.
> 
> For example disabling and enabling modules:
> 
> so for example:
> 
> semodule -d irc (disabled it: confirmed with sesearch)
> cd cilpolicy xargs -a LISTING semodule -i
> (tells me that it will disable irc module after install because its set
> disabled: confirmed with sesearch)
> semodule -e irc (enables it again: confirmed with sesearch)
> 
> 

Yes, looking into some more, I think you're right. There's a bug
somewhere. Still looking into it.

Thanks,
- Steve

Re: [RFC] CIL and Source Policy Integration

[Dominick Grift]

On Thu, 2014-01-09 at 11:22 -0500, Steve Lawrence wrote:

> 
> Yes, looking into some more, I think you're right. There's a bug
> somewhere. Still looking into it.
> 

Thank you. I do not want to flood this thread so i will only post if i
find issues, everything else works as far as i am concerned.

For example i just tested toggling booleans on and off with setsebool,
and that worked fine as well.

I am currently only focusing on CIL, not on whether the user space
modifications are backwards compatible.

> Thanks,
> - Steve

Re: [RFC] CIL and Source Policy Integration

[Stephen Smalley]

On 01/08/2014 03:44 PM, Steve Lawrence wrote:
> As has been posted to this list before in the past, we have made a lot
> of progress with CIL [1]. Although we are still making changes, we are
> now capable of building SELinux binary policies from CIL versions of
> refpolicy and SEAndroid policy. A related project that we are working
> on, and the purpose of this RFC, is to modify SELinux userspace to
> include the CIL and the Source Policy work completed a few years ago.
> We have completed a preliminary integration, so we are sending out this
> RFC to start discussions and ask questions. To start it off, what is in
> the way of getting these branches merged into master, and how can we
> help mitigate that? Are the any changes that you question? Can we find
> a work around?
> 
> Instead of sending the patchset to this list (54 commits, 4000
> insertions, 2000 deletions), all the changes are pushed to the selinux
> git repository to the following three branches, each one building on the
> other. The branches and their purpose is described below:
> 
> src-revert:
>    Reverts changes made to master that conflict with the src-policy
>    branch (e.g. how paths are handled, enabled/disable modules). Rather
>    than dealing with a large amount of conflicts, it was easier to just
>    remove the commits which add conflicting features, rebase the old
>    source policy work on top of that, and add back any features that in
>    manner consistent with source policy. This also reverts the preserve
>    tunables patchset, but as I look at it while typing this, I realize
>    that was unnecessary. Aside from numerous conflicts and the need to
>    add CIL support, the only real issue is that the preserve tunables
>    feature uses the -P flag, which source policy uses for priority. So I
>    guess we'll have to pick a different letter.

Obviously we'll need that support as it is used.

> integration:
>    This branch builds CIL into libsepol, and updates libsepol,
>    libsemanage, semodule, and semanage to work with and understand only
>    CIL files.  Switching to CIL has a few side effects, such as removing
>    base modules, versions, upgrades, adding configuration options to
>    semanage.conf, etc. This also removes support for binary .pp modules.

So what's the transition plan for distributions with existing binary .pp
modules, some of which will be locally generated by users?

Re: [RFC] CIL and Source Policy Integration

[Steve Lawrence]

On 01/09/2014 11:15 AM, Stephen Smalley wrote:
> On 01/08/2014 03:44 PM, Steve Lawrence wrote:
>>
>> src-revert:
>>    Reverts changes made to master that conflict with the src-policy
>>    branch (e.g. how paths are handled, enabled/disable modules). Rather
>>    than dealing with a large amount of conflicts, it was easier to just
>>    remove the commits which add conflicting features, rebase the old
>>    source policy work on top of that, and add back any features that in
>>    manner consistent with source policy. This also reverts the preserve
>>    tunables patchset, but as I look at it while typing this, I realize
>>    that was unnecessary. Aside from numerous conflicts and the need to
>>    add CIL support, the only real issue is that the preserve tunables
>>    feature uses the -P flag, which source policy uses for priority. So I
>>    guess we'll have to pick a different letter.
> 
> Obviously we'll need that support as it is used.
> 

Agreed

>> integration:
>>    This branch builds CIL into libsepol, and updates libsepol,
>>    libsemanage, semodule, and semanage to work with and understand only
>>    CIL files.  Switching to CIL has a few side effects, such as removing
>>    base modules, versions, upgrades, adding configuration options to
>>    semanage.conf, etc. This also removes support for binary .pp modules.
> 
> So what's the transition plan for distributions with existing binary .pp
> modules, some of which will be locally generated by users?
> 

This is a tricky problem. A few ways I've thought (there's probably some
more, I'm all ears):

1) Add high level language support, treat .pp files as a higher level
language, and create a pp to cil converter. I think reversing .pp files
was looked at in the past (I forget who or where it ended up), though
I'm not sure how easy it would be translate a .pp to .cil. This would
probably be ideal and would minimize the transition pain, but the
difficulty of converting pp to cil is unknown to me.

2) Similar to 1, add high level language support, but have distributions
switch over to using source refpolicy, and have a te/if/fc to cil
converter. This would be nice in that distros could still work off of
the familiar refpolicy. The downsides are this doesn't solve the problem
of users with custom .pp modules, and as Jim has found out, converting
from source refpolicy to cil is not an easy process, and requires some
manual intervention. It's possible we could start massaging refpolicy
into something that is easier to automatically convert to cil, but I
don't know what would be needed.

3) Add a configuration option (semanage.conf?) which specifies which
format the module store is in (pp vs cil). Userspace always supports
both, but only one at a time. The downside of this is we have to
maintain two separate policy types. We could eventually deprecate .pp
support, but it might take a while before everyone switches over to cil
to the point where we could deprecate.

- Steve

Re: [RFC] CIL and Source Policy Integration

[James Carter]

On 01/09/2014 11:56 AM, Steve Lawrence wrote:
> On 01/09/2014 11:15 AM, Stephen Smalley wrote:
>> On 01/08/2014 03:44 PM, Steve Lawrence wrote:
>>>
>>> src-revert:
>>>     Reverts changes made to master that conflict with the src-policy
>>>     branch (e.g. how paths are handled, enabled/disable modules). Rather
>>>     than dealing with a large amount of conflicts, it was easier to just
>>>     remove the commits which add conflicting features, rebase the old
>>>     source policy work on top of that, and add back any features that in
>>>     manner consistent with source policy. This also reverts the preserve
>>>     tunables patchset, but as I look at it while typing this, I realize
>>>     that was unnecessary. Aside from numerous conflicts and the need to
>>>     add CIL support, the only real issue is that the preserve tunables
>>>     feature uses the -P flag, which source policy uses for priority. So I
>>>     guess we'll have to pick a different letter.
>>
>> Obviously we'll need that support as it is used.
>>
>
> Agreed
>
>>> integration:
>>>     This branch builds CIL into libsepol, and updates libsepol,
>>>     libsemanage, semodule, and semanage to work with and understand only
>>>     CIL files.  Switching to CIL has a few side effects, such as removing
>>>     base modules, versions, upgrades, adding configuration options to
>>>     semanage.conf, etc. This also removes support for binary .pp modules.
>>
>> So what's the transition plan for distributions with existing binary .pp
>> modules, some of which will be locally generated by users?
>>
>
> This is a tricky problem. A few ways I've thought (there's probably some
> more, I'm all ears):
>
> 1) Add high level language support, treat .pp files as a higher level
> language, and create a pp to cil converter. I think reversing .pp files
> was looked at in the past (I forget who or where it ended up), though
> I'm not sure how easy it would be translate a .pp to .cil. This would
> probably be ideal and would minimize the transition pain, but the
> difficulty of converting pp to cil is unknown to me.
>

A pp to cil converter should not be too hard in general, since all the m4 stuff 
has been expanded. But it would be better to convert from source.

> 2) Similar to 1, add high level language support, but have distributions
> switch over to using source refpolicy, and have a te/if/fc to cil
> converter. This would be nice in that distros could still work off of
> the familiar refpolicy. The downsides are this doesn't solve the problem
> of users with custom .pp modules, and as Jim has found out, converting
> from source refpolicy to cil is not an easy process, and requires some
> manual intervention. It's possible we could start massaging refpolicy
> into something that is easier to automatically convert to cil, but I
> don't know what would be needed.
>

I don't think the distro policy presents too much of a problem. Conversion 
requires patching the old refpolicy tree in a few places (maybe more for 
Fedora's policy), but once the conversion is done, both Refpolicy packages and 
CIL source can be generated from the same policy without any manual intervention.

There have already been some patches made to Refpolicy to make it easier to 
convert to CIL and I am willing to generate new patches. I have also done some 
work on Fedora's policy to see what is needed to convert it to CIL, but have 
been spending more time on the CIL compiler recently.

Converting the module source is easy if the rest of the policy is around in a 
form that can be converted to CIL. It shouldn't be too hard to make a tool that 
can read in a CIL policy and a Refpolicy source module and output a CIL source 
module and I plan on doing that.

> 3) Add a configuration option (semanage.conf?) which specifies which
> format the module store is in (pp vs cil). Userspace always supports
> both, but only one at a time. The downside of this is we have to
> maintain two separate policy types. We could eventually deprecate .pp
> support, but it might take a while before everyone switches over to cil
> to the point where we could deprecate.
>

We probably need to do this regardless, don't we?

-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

Re: [RFC] CIL and Source Policy Integration

[Steve Lawrence]

On 01/09/2014 01:34 PM, James Carter wrote:
> On 01/09/2014 11:56 AM, Steve Lawrence wrote:
>> On 01/09/2014 11:15 AM, Stephen Smalley wrote:
>>> On 01/08/2014 03:44 PM, Steve Lawrence wrote:
>>>>
>>>> src-revert:
>>>>     Reverts changes made to master that conflict with the src-policy
>>>>     branch (e.g. how paths are handled, enabled/disable modules).
>>>> Rather
>>>>     than dealing with a large amount of conflicts, it was easier to
>>>> just
>>>>     remove the commits which add conflicting features, rebase the old
>>>>     source policy work on top of that, and add back any features
>>>> that in
>>>>     manner consistent with source policy. This also reverts the
>>>> preserve
>>>>     tunables patchset, but as I look at it while typing this, I realize
>>>>     that was unnecessary. Aside from numerous conflicts and the need to
>>>>     add CIL support, the only real issue is that the preserve tunables
>>>>     feature uses the -P flag, which source policy uses for priority.
>>>> So I
>>>>     guess we'll have to pick a different letter.
>>>
>>> Obviously we'll need that support as it is used.
>>>
>>
>> Agreed
>>
>>>> integration:
>>>>     This branch builds CIL into libsepol, and updates libsepol,
>>>>     libsemanage, semodule, and semanage to work with and understand
>>>> only
>>>>     CIL files.  Switching to CIL has a few side effects, such as
>>>> removing
>>>>     base modules, versions, upgrades, adding configuration options to
>>>>     semanage.conf, etc. This also removes support for binary .pp
>>>> modules.
>>>
>>> So what's the transition plan for distributions with existing binary .pp
>>> modules, some of which will be locally generated by users?
>>>
>>
>> This is a tricky problem. A few ways I've thought (there's probably some
>> more, I'm all ears):
>>
>> 1) Add high level language support, treat .pp files as a higher level
>> language, and create a pp to cil converter. I think reversing .pp files
>> was looked at in the past (I forget who or where it ended up), though
>> I'm not sure how easy it would be translate a .pp to .cil. This would
>> probably be ideal and would minimize the transition pain, but the
>> difficulty of converting pp to cil is unknown to me.
>>
> 
> A pp to cil converter should not be too hard in general, since all the
> m4 stuff has been expanded. But it would be better to convert from source.
> 
>> 2) Similar to 1, add high level language support, but have distributions
>> switch over to using source refpolicy, and have a te/if/fc to cil
>> converter. This would be nice in that distros could still work off of
>> the familiar refpolicy. The downsides are this doesn't solve the problem
>> of users with custom .pp modules, and as Jim has found out, converting
>> from source refpolicy to cil is not an easy process, and requires some
>> manual intervention. It's possible we could start massaging refpolicy
>> into something that is easier to automatically convert to cil, but I
>> don't know what would be needed.
>>
> 
> I don't think the distro policy presents too much of a problem.
> Conversion requires patching the old refpolicy tree in a few places
> (maybe more for Fedora's policy), but once the conversion is done, both
> Refpolicy packages and CIL source can be generated from the same policy
> without any manual intervention.
> 
> There have already been some patches made to Refpolicy to make it easier
> to convert to CIL and I am willing to generate new patches. I have also
> done some work on Fedora's policy to see what is needed to convert it to
> CIL, but have been spending more time on the CIL compiler recently.
> 
> Converting the module source is easy if the rest of the policy is around
> in a form that can be converted to CIL. It shouldn't be too hard to make
> a tool that can read in a CIL policy and a Refpolicy source module and
> output a CIL source module and I plan on doing that.
> 
>> 3) Add a configuration option (semanage.conf?) which specifies which
>> format the module store is in (pp vs cil). Userspace always supports
>> both, but only one at a time. The downside of this is we have to
>> maintain two separate policy types. We could eventually deprecate .pp
>> support, but it might take a while before everyone switches over to cil
>> to the point where we could deprecate.
>>
> 
> We probably need to do this regardless, don't we?
> 

It's probably a good idea, but I don't think it's necessary in all
cases. As long as we also add support for converting .pp files to .cil
(like in 1), once you install the new userspace it could just consider
all existing .pp files as an HLL and convert them to CIL when building a
new policy.

If we had a transition plan that did not include the ability to convert
pp files, then yes, we would definitely need it configurable.

- Steve

Re: [RFC] CIL and Source Policy Integration

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/09/2014 11:56 AM, Steve Lawrence wrote:
> On 01/09/2014 11:15 AM, Stephen Smalley wrote:
>> On 01/08/2014 03:44 PM, Steve Lawrence wrote:
>>> 
>>> src-revert: Reverts changes made to master that conflict with the
>>> src-policy branch (e.g. how paths are handled, enabled/disable
>>> modules). Rather than dealing with a large amount of conflicts, it was
>>> easier to just remove the commits which add conflicting features,
>>> rebase the old source policy work on top of that, and add back any
>>> features that in manner consistent with source policy. This also
>>> reverts the preserve tunables patchset, but as I look at it while
>>> typing this, I realize that was unnecessary. Aside from numerous
>>> conflicts and the need to add CIL support, the only real issue is that
>>> the preserve tunables feature uses the -P flag, which source policy
>>> uses for priority. So I guess we'll have to pick a different letter.
>> 
>> Obviously we'll need that support as it is used.
>> 
> 
> Agreed
> 
>>> integration: This branch builds CIL into libsepol, and updates
>>> libsepol, libsemanage, semodule, and semanage to work with and
>>> understand only CIL files.  Switching to CIL has a few side effects,
>>> such as removing base modules, versions, upgrades, adding configuration
>>> options to semanage.conf, etc. This also removes support for binary .pp
>>> modules.
>> 
>> So what's the transition plan for distributions with existing binary .pp 
>> modules, some of which will be locally generated by users?
>> 
> 
> This is a tricky problem. A few ways I've thought (there's probably some 
> more, I'm all ears):
> 
> 1) Add high level language support, treat .pp files as a higher level 
> language, and create a pp to cil converter. I think reversing .pp files was
> looked at in the past (I forget who or where it ended up), though I'm not
> sure how easy it would be translate a .pp to .cil. This would probably be
> ideal and would minimize the transition pain, but the difficulty of
> converting pp to cil is unknown to me.
> 
It has got to be this one.  Remember you also have a huge amount of "google"
knowledge out there.  People will be writing pp files for a while.

> 2) Similar to 1, add high level language support, but have distributions 
> switch over to using source refpolicy, and have a te/if/fc to cil 
> converter. This would be nice in that distros could still work off of the
> familiar refpolicy. The downsides are this doesn't solve the problem of
> users with custom .pp modules, and as Jim has found out, converting from
> source refpolicy to cil is not an easy process, and requires some manual
> intervention. It's possible we could start massaging refpolicy into
> something that is easier to automatically convert to cil, but I don't know
> what would be needed.
> 
> 3) Add a configuration option (semanage.conf?) which specifies which format
> the module store is in (pp vs cil). Userspace always supports both, but
> only one at a time. The downside of this is we have to maintain two
> separate policy types. We could eventually deprecate .pp support, but it
> might take a while before everyone switches over to cil to the point where
> we could deprecate.
> 
> - Steve _______________________________________________ Selinux mailing
> list Selinux@tycho.nsa.gov To unsubscribe, send email to
> Selinux-leave@tycho.nsa.gov. To get help, send an email containing "help"
> to Selinux-request@tycho.nsa.gov.
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLPCsUACgkQrlYvE4MpobNWmwCfTNOaPPIpnGX+yIVkffNhDJ6L
QQkAmgPt3w7LoRo/q0D0FmWLCTkz+mDN
=wjQm
-----END PGP SIGNATURE-----

Re: [RFC] CIL and Source Policy Integration

[Stephen Smalley]

On 01/09/2014 03:47 PM, Daniel J Walsh wrote:
> On 01/09/2014 11:56 AM, Steve Lawrence wrote:
>> On 01/09/2014 11:15 AM, Stephen Smalley wrote:
>>> On 01/08/2014 03:44 PM, Steve Lawrence wrote:
>>>>
>>>> src-revert: Reverts changes made to master that conflict with the
>>>> src-policy branch (e.g. how paths are handled, enabled/disable
>>>> modules). Rather than dealing with a large amount of conflicts, it was
>>>> easier to just remove the commits which add conflicting features,
>>>> rebase the old source policy work on top of that, and add back any
>>>> features that in manner consistent with source policy. This also
>>>> reverts the preserve tunables patchset, but as I look at it while
>>>> typing this, I realize that was unnecessary. Aside from numerous
>>>> conflicts and the need to add CIL support, the only real issue is that
>>>> the preserve tunables feature uses the -P flag, which source policy
>>>> uses for priority. So I guess we'll have to pick a different letter.
>>>
>>> Obviously we'll need that support as it is used.
>>>
> 
>> Agreed
> 
>>>> integration: This branch builds CIL into libsepol, and updates
>>>> libsepol, libsemanage, semodule, and semanage to work with and
>>>> understand only CIL files.  Switching to CIL has a few side effects,
>>>> such as removing base modules, versions, upgrades, adding configuration
>>>> options to semanage.conf, etc. This also removes support for binary .pp
>>>> modules.
>>>
>>> So what's the transition plan for distributions with existing binary .pp 
>>> modules, some of which will be locally generated by users?
>>>
> 
>> This is a tricky problem. A few ways I've thought (there's probably some 
>> more, I'm all ears):
> 
>> 1) Add high level language support, treat .pp files as a higher level 
>> language, and create a pp to cil converter. I think reversing .pp files was
>> looked at in the past (I forget who or where it ended up), though I'm not
>> sure how easy it would be translate a .pp to .cil. This would probably be
>> ideal and would minimize the transition pain, but the difficulty of
>> converting pp to cil is unknown to me.
> 
> It has got to be this one.  Remember you also have a huge amount of "google"
> knowledge out there.  People will be writing pp files for a while.

Yes, I agree.  semodule_unpackage and checkpolicy/test/dismod should get
you part of the way there, but you'll have to turn dismod into a full
featured disassembler for binary modules and have it generate cil.
We have to assume that people will have .pp files for which they no
longer have source, especially audit2allow -M generated ones.