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

[Stephen Smalley <sds@tycho.nsa.gov>]

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?

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

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

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?