From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <53CD52D9.6020107@tresys.com>
Date: Mon, 21 Jul 2014 13:50:17 -0400
From: Steve Lawrence <slawrence@tresys.com>
MIME-Version: 1.0
To: Stephen Smalley <sds@tycho.nsa.gov>, Dominick Grift
 <dominick.grift@gmail.com>
Subject: Re: [RFC] Source Policy, CIL, and High Level Languages
References: <53BD9646.6030303@tresys.com>
 <1404975079.31209.11.camel@x220.localdomain> <53C944AC.4080605@tresys.com>
 <53C96305.60109@tycho.nsa.gov> <53CD24EA.90903@tresys.com>
 <53CD28F7.6030104@tycho.nsa.gov>
In-Reply-To: <53CD28F7.6030104@tycho.nsa.gov>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: SELinux List <selinux@tycho.nsa.gov>
List-Id: "Security-Enhanced Linux \(SELinux\) mailing list"
 <selinux.tycho.nsa.gov>
List-Post: <mailto:selinux@tycho.nsa.gov>
List-Help: <mailto:selinux-request@tycho.nsa.gov?subject=help>

On 07/21/2014 10:51 AM, Stephen Smalley wrote:
> On 07/21/2014 10:34 AM, Steve Lawrence wrote:
>> On 07/18/2014 02:10 PM, Stephen Smalley wrote:
>>> On 07/18/2014 12:00 PM, Steve Lawrence wrote:
>>>> On 07/10/2014 02:51 AM, Dominick Grift wrote:
>>>>> On Wed, 2014-07-09 at 15:21 -0400, Steve Lawrence wrote:
>>>>>> In January, we sent an RFC [1] to update userspace to integrate CIL
>>>>>> [2] and source policy. And in April, we sent an updated RFC [3] which
>>>>>> added support for high level languages and a tool to convert policy
>>>>>> package (pp) files to CIL. After getting some good feedback, we have
>>>>>> made some more changes, mostly to maintain ABI compatibility. The
>>>>>> major changes made since the last patchset are:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>> After associating user john with staff_u, johns home directory is
>>>>> properly labeled (staff_u associated with /home/john). However, what is
>>>>> strange here is that i cannot see staff_u home dir context specs
>>>>> in /var/lib/selinux/targeted/active/modules/file_contexts.homedirs
>>>>>  
>>>>> Am i looking in the wrong place? How does SELinux know that staff_u
>>>>> needs to be associated with /home/john
>>>>>
>>>>
>>>> In the current upatream, file_contexts.homedirs is autogenerated and
>>>> created in /etc/selinux/targeted/modules/active/ before it is copied to
>>>> /etc/selinux/targeted/contexts/files. This file is not removed from the
>>>> store, so it actually exists in two places.
>>>>
>>>> However, with the new source policy work, file_contexts.homedirs is
>>>> generated in a temporary sandbox (not the policy store). The contents of
>>>> the sandbox are copied to /etc/selinux, and then deleted at the end of
>>>> the transaction. So the new source policy infrastructure no longer
>>>> stores intermediate/final build files in the policy store.
>>>>
>>>> However, the migration script copies all the files from the old store to
>>>> the new store, even including autogenerated files that the new source
>>>> policy infrastructure will never look at or touch. This is just a bug in
>>>> the migration script. We've updated the migration script to only migrate
>>>> the files that actually need to be migrated (mostly *.local files). This
>>>> has been rebased/pushed to github #integration branch.
>>>
>>> If I run semanage_migrate_etc_to_var.py -n on a clean (no
>>> /var/lib/selinux at all) system, the /var/lib/selinux/targeted/active
>>> directory contains a homedir_template and a netfilter_contexts file in
>>> addition to the modules (and commit_num).  The first file is
>>> automatically extracted from all of the file contexts during build and
>>> the second is unused these days.  If I then run semodule -B (or omit the
>>> -n option on migration), I further have file_contexts.template and
>>> users_extra files under active, both of which are also generated.  I can
>>> delete all four files and regenerate all but netfilter_contexts via
>>> semodule -B.
>>>
>>
>> This has been fixed. Just needed to remove a couple more paths from the
>> migration script and add a couple of unlink()'s in direct_commit().
> 
> Thanks.  I had a question though about the approach being used in the
> new libsemanage for populating /var/lib/selinux/tmp/targeted initially
> (not to be confused with /var/lib/selinux/targeted/tmp, which frankly I
> do find rather confusing even though I understand it now).  libsemanage
> copies the entire /etc/selinux/targeted directory layout (but not all
> the files) under /var/lib/selinux/tmp/targeted, even directories that it
> will never use (including e.g. the old modules directory), and then
> copies the files it manages from /etc/selinux/targeted to the
> corresponding /var/lib/selinux/tmp/targeted location before generating
> the new policy.  This raises a few questions in my mind:
> 
> - Is it a good idea to depend on an already existing and populated
> /etc/selinux/targeted directory tree?

Wouldn't hurt to just create the directories we need.

> - Why copy the entire directory structure rather than just creating the
> directories we know we will need?

Yeah, seems unnecessary.

> - What exactly is the dependency here?  If there is a mismatch between
> the built files in /etc/selinux/targeted and the
> /var/lib/selinux/targeted/active tree, can bad things happen?  Is
> libsemanage depending on those prebuilt files being identical to what
> would be generated if it did a rebuild from
> /var/lib/selinux/targeted/active?  If not, why does it need them at all?

>>From what I can tell, I think the files in /etc/selinux/targeted are
copied over for the cases where it doesn't rebuild policies (e.g.
changes to local fcontexts, seusers, ports, etc), but needs the current
policy files for validation. We'll look into how how drastic this change
would be.

Another thing that I think is incorrect is how file_context.local is
handle. That is stored in /etc/selinux/targeted/contexts/files, but it
seems like that should just be stored in
/var/lib/selinux/targeted/active/ just like other local modification
files, and merged into the file_contexts file. Not sure the reasoning
for keeping it separate.

> It looks to me as if possibly the old libsemanage relied on having
> policy.kern locally available in the sandbox, then RH switched it to a
> symlink to the installed file (wrongly, I think, as this would seemingly
> break a revert to prior policy), and this made it also depend on the
> installed policy file.  And it appears to assume that the directory
> structure at least already exists under /etc/selinux/targeted.  But this
> seems to take it a step further.  How do I bootstrap a policy install
> with no prior /etc/selinux/targeted directory?

I think all you really need is the directory structure set up, but it
should be a pretty simple fix so even that isn't required.