question about semanage fcontext and awareness of file_contexts.local file

question about semanage fcontext and awareness of file_contexts.local file

[Bond Masuda]

We want to add some custom file contexts for certain directories, in
particular we have /audit as a separate partition and run this:

chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"

To make sure auditd works. This is run with chroot because the system
we're modifying is not running and mounted at /mnt/root. This creates
the file_contexts.local file with this content:

# This file is auto-generated by libsemanage
# Do not edit directly.

/audit(/.*)?    system_u:object_r:auditd_log_t:s0

Later on, when we boot that system that was in /mnt/root, the
file_contexts.local remains the same. However, if I run semanage to add
another record, for example (this time, not in chroot):

semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"

It creates the content for httpd_sys_content_t in file_contexts.local,
but overwrites the previous entry for auditd_log_t.

If I add the auditd_log_t entry once again, _both_ entries are now
present in file_contexts.local. So, it seems that the 1st time I run
semanage fcontext -a _while_ the system is running, it is not aware of
the content that was added when I ran semanage fcontext -a when the
system was offline and mounted in /mnt/root.

Does semanage maintain state somewhere other than in the
file_contexts.local file? How can I make sure it is aware of the content
in file_contexts.local that was created by semanage when it was run in
chroot?

Thanks,
-Bond

Re: question about semanage fcontext and awareness of file_contexts.local file

[Stephen Smalley]

On 08/17/2015 07:42 PM, Bond Masuda wrote:
> We want to add some custom file contexts for certain directories, in
> particular we have /audit as a separate partition and run this:
> 
> chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
> 
> To make sure auditd works. This is run with chroot because the system
> we're modifying is not running and mounted at /mnt/root. This creates
> the file_contexts.local file with this content:
> 
> # This file is auto-generated by libsemanage
> # Do not edit directly.
> 
> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
> 
> Later on, when we boot that system that was in /mnt/root, the
> file_contexts.local remains the same. However, if I run semanage to add
> another record, for example (this time, not in chroot):
> 
> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
> 
> It creates the content for httpd_sys_content_t in file_contexts.local,
> but overwrites the previous entry for auditd_log_t.
> 
> If I add the auditd_log_t entry once again, _both_ entries are now
> present in file_contexts.local. So, it seems that the 1st time I run
> semanage fcontext -a _while_ the system is running, it is not aware of
> the content that was added when I ran semanage fcontext -a when the
> system was offline and mounted in /mnt/root.
> 
> Does semanage maintain state somewhere other than in the
> file_contexts.local file? How can I make sure it is aware of the content
> in file_contexts.local that was created by semanage when it was run in
> chroot?

This sounds like a bug to me.  What version of libsemanage and
policycoreutils are you using, as this may be version-specific?

Re: question about semanage fcontext and awareness of file_contexts.local file

[Bond Masuda]

On 08/24/2015 11:15 AM, Stephen Smalley wrote:
> On 08/17/2015 07:42 PM, Bond Masuda wrote:
>> We want to add some custom file contexts for certain directories, in
>> particular we have /audit as a separate partition and run this:
>>
>> chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
>>
>> To make sure auditd works. This is run with chroot because the system
>> we're modifying is not running and mounted at /mnt/root. This creates
>> the file_contexts.local file with this content:
>>
>> # This file is auto-generated by libsemanage
>> # Do not edit directly.
>>
>> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
>>
>> Later on, when we boot that system that was in /mnt/root, the
>> file_contexts.local remains the same. However, if I run semanage to add
>> another record, for example (this time, not in chroot):
>>
>> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
>>
>> It creates the content for httpd_sys_content_t in file_contexts.local,
>> but overwrites the previous entry for auditd_log_t.
>>
>> If I add the auditd_log_t entry once again, _both_ entries are now
>> present in file_contexts.local. So, it seems that the 1st time I run
>> semanage fcontext -a _while_ the system is running, it is not aware of
>> the content that was added when I ran semanage fcontext -a when the
>> system was offline and mounted in /mnt/root.
>>
>> Does semanage maintain state somewhere other than in the
>> file_contexts.local file? How can I make sure it is aware of the content
>> in file_contexts.local that was created by semanage when it was run in
>> chroot?
> This sounds like a bug to me.  What version of libsemanage and
> policycoreutils are you using, as this may be version-specific?
>
>

The versions are:

libsemanage-2.0.43-5.1.el6.x86_64
libsemanage-python-2.0.43-5.1.el6.x86_64
policycoreutils-2.0.83-24.el6.x86_64
policycoreutils-python-2.0.83-24.el6.x86_64

Thanks,
-Bond

Re: question about semanage fcontext and awareness of file_contexts.local file

[Stephen Smalley]

On 08/24/2015 02:22 PM, Bond Masuda wrote:
> 
> 
> On 08/24/2015 11:15 AM, Stephen Smalley wrote:
>> On 08/17/2015 07:42 PM, Bond Masuda wrote:
>>> We want to add some custom file contexts for certain directories, in
>>> particular we have /audit as a separate partition and run this:
>>>
>>> chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
>>>
>>> To make sure auditd works. This is run with chroot because the system
>>> we're modifying is not running and mounted at /mnt/root. This creates
>>> the file_contexts.local file with this content:
>>>
>>> # This file is auto-generated by libsemanage
>>> # Do not edit directly.
>>>
>>> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
>>>
>>> Later on, when we boot that system that was in /mnt/root, the
>>> file_contexts.local remains the same. However, if I run semanage to add
>>> another record, for example (this time, not in chroot):
>>>
>>> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
>>>
>>> It creates the content for httpd_sys_content_t in file_contexts.local,
>>> but overwrites the previous entry for auditd_log_t.
>>>
>>> If I add the auditd_log_t entry once again, _both_ entries are now
>>> present in file_contexts.local. So, it seems that the 1st time I run
>>> semanage fcontext -a _while_ the system is running, it is not aware of
>>> the content that was added when I ran semanage fcontext -a when the
>>> system was offline and mounted in /mnt/root.
>>>
>>> Does semanage maintain state somewhere other than in the
>>> file_contexts.local file? How can I make sure it is aware of the content
>>> in file_contexts.local that was created by semanage when it was run in
>>> chroot?
>> This sounds like a bug to me.  What version of libsemanage and
>> policycoreutils are you using, as this may be version-specific?
>>
>>
> 
> The versions are:
> 
> libsemanage-2.0.43-5.1.el6.x86_64
> libsemanage-python-2.0.43-5.1.el6.x86_64
> policycoreutils-2.0.83-24.el6.x86_64
> policycoreutils-python-2.0.83-24.el6.x86_64

So in that case, I'd expect that each semanage fcontext -a command would
generate a file_contexts.local file under
/etc/selinux/targeted/modules/active/ and under
/etc/selinux/targeted/contexts/files/.  The first one is the private
copy generated and used within the policy module store only, and the
latter is the public copy installed at the end of the transaction and
used by other programs like restorecon to look up file labels.  They
should be identical at the end of the semanage command.

Is this reproducible?  If so, it would be interesting the compare the
two files before and after each of the semanage commands you ran.

Re: question about semanage fcontext and awareness of file_contexts.local file

[Bond Masuda]

On 08/24/2015 01:09 PM, Stephen Smalley wrote:
> On 08/24/2015 02:22 PM, Bond Masuda wrote:
>>
>> On 08/24/2015 11:15 AM, Stephen Smalley wrote:
>>> On 08/17/2015 07:42 PM, Bond Masuda wrote:
>>>> We want to add some custom file contexts for certain directories, in
>>>> particular we have /audit as a separate partition and run this:
>>>>
>>>> chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
>>>>
>>>> To make sure auditd works. This is run with chroot because the system
>>>> we're modifying is not running and mounted at /mnt/root. This creates
>>>> the file_contexts.local file with this content:
>>>>
>>>> # This file is auto-generated by libsemanage
>>>> # Do not edit directly.
>>>>
>>>> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
>>>>
>>>> Later on, when we boot that system that was in /mnt/root, the
>>>> file_contexts.local remains the same. However, if I run semanage to add
>>>> another record, for example (this time, not in chroot):
>>>>
>>>> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
>>>>
>>>> It creates the content for httpd_sys_content_t in file_contexts.local,
>>>> but overwrites the previous entry for auditd_log_t.
>>>>
>>>> If I add the auditd_log_t entry once again, _both_ entries are now
>>>> present in file_contexts.local. So, it seems that the 1st time I run
>>>> semanage fcontext -a _while_ the system is running, it is not aware of
>>>> the content that was added when I ran semanage fcontext -a when the
>>>> system was offline and mounted in /mnt/root.
>>>>
>>>> Does semanage maintain state somewhere other than in the
>>>> file_contexts.local file? How can I make sure it is aware of the content
>>>> in file_contexts.local that was created by semanage when it was run in
>>>> chroot?
>>> This sounds like a bug to me.  What version of libsemanage and
>>> policycoreutils are you using, as this may be version-specific?
>>>
>>>
>> The versions are:
>>
>> libsemanage-2.0.43-5.1.el6.x86_64
>> libsemanage-python-2.0.43-5.1.el6.x86_64
>> policycoreutils-2.0.83-24.el6.x86_64
>> policycoreutils-python-2.0.83-24.el6.x86_64
> So in that case, I'd expect that each semanage fcontext -a command would
> generate a file_contexts.local file under
> /etc/selinux/targeted/modules/active/ and under
> /etc/selinux/targeted/contexts/files/.  The first one is the private
> copy generated and used within the policy module store only, and the
> latter is the public copy installed at the end of the transaction and
> used by other programs like restorecon to look up file labels.  They
> should be identical at the end of the semanage command.
>
> Is this reproducible?  If so, it would be interesting the compare the
> two files before and after each of the semanage commands you ran.

Stephen,

Thanks for the info above. I didn't know the information was in two
places. When running the semanage command in chroot to /mnt/root, I get
a file in
/mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local, but I
do *NOT* get /mnt/root/etc/selinux/targeted/modules/active. The contents
of the "active" directory are:

[root@localhost active]# ls -al
total 9052
drwx------. 3 root root    4096 Aug 25 14:35 .
drwxr-xr-x. 3 root root      70 Aug 25 14:36 ..
-rw-------. 1 root root  249117 Aug 25 14:35 base.pp
-rw-------. 1 root root      32 Aug 25 14:35 commit_num
-rw-------. 1 root root  290786 Aug 25 14:35 file_contexts
-rw-r--r--. 1 root root    6405 Aug 25 14:35 file_contexts.homedirs
-rw-------. 1 root root  296417 Aug 25 14:35 file_contexts.template
-rw-------. 1 root root    5631 Aug 25 14:35 homedir_template
drwx------. 2 root root    8192 Aug 25 14:35 modules
-rw-------. 1 root root       0 Aug 25 14:35 netfilter_contexts
-rw-r--r--. 1 root root 8380527 Aug 25 14:35 policy.kern
-rw-------. 1 root root     106 Aug 25 14:35 seusers.final
-rw-------. 1 root root     101 Aug 25 14:35 users_extra


The contents of the "files" directory are:

[root@localhost files]# ls -al
total 304
drwxr-xr-x. 2 root root     93 Aug 25 14:36 .
drwxr-xr-x. 4 root root   4096 Aug 25 14:36 ..
-rw-r--r--. 1 root root 290786 Aug 25 14:36 file_contexts
-rw-r--r--. 1 root root   6405 Aug 25 14:36 file_contexts.homedirs
-rw-r--r--. 1 root root    120 Aug 25 14:36 file_contexts.local
-rw-r--r--. 1 root root    139 Aug 13 02:37 media

So, is this a bug? Or, intended behavior due to some condition of
running semanage in chroot?

Thanks,
-Bond

Re: question about semanage fcontext and awareness of file_contexts.local file

[Stephen Smalley]

On 08/25/2015 06:46 PM, Bond Masuda wrote:
> 
> 
> On 08/24/2015 01:09 PM, Stephen Smalley wrote:
>> On 08/24/2015 02:22 PM, Bond Masuda wrote:
>>>
>>> On 08/24/2015 11:15 AM, Stephen Smalley wrote:
>>>> On 08/17/2015 07:42 PM, Bond Masuda wrote:
>>>>> We want to add some custom file contexts for certain directories, in
>>>>> particular we have /audit as a separate partition and run this:
>>>>>
>>>>> chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"
>>>>>
>>>>> To make sure auditd works. This is run with chroot because the system
>>>>> we're modifying is not running and mounted at /mnt/root. This creates
>>>>> the file_contexts.local file with this content:
>>>>>
>>>>> # This file is auto-generated by libsemanage
>>>>> # Do not edit directly.
>>>>>
>>>>> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
>>>>>
>>>>> Later on, when we boot that system that was in /mnt/root, the
>>>>> file_contexts.local remains the same. However, if I run semanage to add
>>>>> another record, for example (this time, not in chroot):
>>>>>
>>>>> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
>>>>>
>>>>> It creates the content for httpd_sys_content_t in file_contexts.local,
>>>>> but overwrites the previous entry for auditd_log_t.
>>>>>
>>>>> If I add the auditd_log_t entry once again, _both_ entries are now
>>>>> present in file_contexts.local. So, it seems that the 1st time I run
>>>>> semanage fcontext -a _while_ the system is running, it is not aware of
>>>>> the content that was added when I ran semanage fcontext -a when the
>>>>> system was offline and mounted in /mnt/root.
>>>>>
>>>>> Does semanage maintain state somewhere other than in the
>>>>> file_contexts.local file? How can I make sure it is aware of the content
>>>>> in file_contexts.local that was created by semanage when it was run in
>>>>> chroot?
>>>> This sounds like a bug to me.  What version of libsemanage and
>>>> policycoreutils are you using, as this may be version-specific?
>>>>
>>>>
>>> The versions are:
>>>
>>> libsemanage-2.0.43-5.1.el6.x86_64
>>> libsemanage-python-2.0.43-5.1.el6.x86_64
>>> policycoreutils-2.0.83-24.el6.x86_64
>>> policycoreutils-python-2.0.83-24.el6.x86_64
>> So in that case, I'd expect that each semanage fcontext -a command would
>> generate a file_contexts.local file under
>> /etc/selinux/targeted/modules/active/ and under
>> /etc/selinux/targeted/contexts/files/.  The first one is the private
>> copy generated and used within the policy module store only, and the
>> latter is the public copy installed at the end of the transaction and
>> used by other programs like restorecon to look up file labels.  They
>> should be identical at the end of the semanage command.
>>
>> Is this reproducible?  If so, it would be interesting the compare the
>> two files before and after each of the semanage commands you ran.
> 
> Stephen,
> 
> Thanks for the info above. I didn't know the information was in two
> places. When running the semanage command in chroot to /mnt/root, I get
> a file in
> /mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local, but I
> do *NOT* get /mnt/root/etc/selinux/targeted/modules/active. The contents
> of the "active" directory are:
> 
> [root@localhost active]# ls -al
> total 9052
> drwx------. 3 root root    4096 Aug 25 14:35 .
> drwxr-xr-x. 3 root root      70 Aug 25 14:36 ..
> -rw-------. 1 root root  249117 Aug 25 14:35 base.pp
> -rw-------. 1 root root      32 Aug 25 14:35 commit_num
> -rw-------. 1 root root  290786 Aug 25 14:35 file_contexts
> -rw-r--r--. 1 root root    6405 Aug 25 14:35 file_contexts.homedirs
> -rw-------. 1 root root  296417 Aug 25 14:35 file_contexts.template
> -rw-------. 1 root root    5631 Aug 25 14:35 homedir_template
> drwx------. 2 root root    8192 Aug 25 14:35 modules
> -rw-------. 1 root root       0 Aug 25 14:35 netfilter_contexts
> -rw-r--r--. 1 root root 8380527 Aug 25 14:35 policy.kern
> -rw-------. 1 root root     106 Aug 25 14:35 seusers.final
> -rw-------. 1 root root     101 Aug 25 14:35 users_extra
> 
> 
> The contents of the "files" directory are:
> 
> [root@localhost files]# ls -al
> total 304
> drwxr-xr-x. 2 root root     93 Aug 25 14:36 .
> drwxr-xr-x. 4 root root   4096 Aug 25 14:36 ..
> -rw-r--r--. 1 root root 290786 Aug 25 14:36 file_contexts
> -rw-r--r--. 1 root root   6405 Aug 25 14:36 file_contexts.homedirs
> -rw-r--r--. 1 root root    120 Aug 25 14:36 file_contexts.local
> -rw-r--r--. 1 root root    139 Aug 13 02:37 media
> 
> So, is this a bug? Or, intended behavior due to some condition of
> running semanage in chroot?

It sounds like a bug. However, I can't reproduce it.  How did you set up
your chroot environment, including how are you handling /proc and
/selinux within the chroot?

Re: question about semanage fcontext and awareness of file_contexts.local file

[Bond Masuda]

wanted to follow up on this thread so anyone in the future searching for 
a solution to this problem can find this.

basically, i'm installing a brand new system in a chroot environment. 
one of our steps to complete the setup requires adding some custom file 
contexts, and so I ran a command like:

chroot /mnt/root semanage fcontext -a -t auditd_log_t "/audit(/.*)?"


So, the curious thing is that I thought this command succeeded because I 
was able to find the file:

/mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local

But it turns out that file should not have been there as the semanage 
command above fails (exit status = 1) and should have rolled back what 
it was attempting to do. This appears to be a bug in my conversations 
with Stephen Smalley.

The reason why semanage fails is because I don't have /selinux in the 
chroot environment, and semanage tries to reload the policy and can't 
and then fails. However, it doesn't make sense for semanage to reload 
the policy of the "host" since the command is meant to make changes to 
the chroot environment of another system i'm installing. Turns out, the 
solution is to use the -N (--noreload) option in semanage:

chroot /mnt/root semanage fcontext -a -N -t auditd_log_t "/audit(/.*)?"


This appears to do the job right and the problem I had that started this 
thread is no longer.

Hope that helps someone..
-Bond

On 08/26/2015 05:55 AM, Stephen Smalley wrote:
> On 08/25/2015 06:46 PM, Bond Masuda wrote:
>>
>> On 08/24/2015 01:09 PM, Stephen Smalley wrote:
>>> On 08/24/2015 02:22 PM, Bond Masuda wrote:
>>>> On 08/24/2015 11:15 AM, Stephen Smalley wrote:
>>>>> On 08/17/2015 07:42 PM, Bond Masuda wrote:
>>>>>> We want to add some custom file contexts for certain directories, in
>>>>>> particular we have /audit as a separate partition and run this:
>>>>>>
>>>>>>
>>>>>>
>>>>>> To make sure auditd works. This is run with chroot because the system
>>>>>> we're modifying is not running and mounted at /mnt/root. This creates
>>>>>> the file_contexts.local file with this content:
>>>>>>
>>>>>> # This file is auto-generated by libsemanage
>>>>>> # Do not edit directly.
>>>>>>
>>>>>> /audit(/.*)?    system_u:object_r:auditd_log_t:s0
>>>>>>
>>>>>> Later on, when we boot that system that was in /mnt/root, the
>>>>>> file_contexts.local remains the same. However, if I run semanage to add
>>>>>> another record, for example (this time, not in chroot):
>>>>>>
>>>>>> semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
>>>>>>
>>>>>> It creates the content for httpd_sys_content_t in file_contexts.local,
>>>>>> but overwrites the previous entry for auditd_log_t.
>>>>>>
>>>>>> If I add the auditd_log_t entry once again, _both_ entries are now
>>>>>> present in file_contexts.local. So, it seems that the 1st time I run
>>>>>> semanage fcontext -a _while_ the system is running, it is not aware of
>>>>>> the content that was added when I ran semanage fcontext -a when the
>>>>>> system was offline and mounted in /mnt/root.
>>>>>>
>>>>>> Does semanage maintain state somewhere other than in the
>>>>>> file_contexts.local file? How can I make sure it is aware of the content
>>>>>> in file_contexts.local that was created by semanage when it was run in
>>>>>> chroot?
>>>>> This sounds like a bug to me.  What version of libsemanage and
>>>>> policycoreutils are you using, as this may be version-specific?
>>>>>
>>>>>
>>>> The versions are:
>>>>
>>>> libsemanage-2.0.43-5.1.el6.x86_64
>>>> libsemanage-python-2.0.43-5.1.el6.x86_64
>>>> policycoreutils-2.0.83-24.el6.x86_64
>>>> policycoreutils-python-2.0.83-24.el6.x86_64
>>> So in that case, I'd expect that each semanage fcontext -a command would
>>> generate a file_contexts.local file under
>>> /etc/selinux/targeted/modules/active/ and under
>>> /etc/selinux/targeted/contexts/files/.  The first one is the private
>>> copy generated and used within the policy module store only, and the
>>> latter is the public copy installed at the end of the transaction and
>>> used by other programs like restorecon to look up file labels.  They
>>> should be identical at the end of the semanage command.
>>>
>>> Is this reproducible?  If so, it would be interesting the compare the
>>> two files before and after each of the semanage commands you ran.
>> Stephen,
>>
>> Thanks for the info above. I didn't know the information was in two
>> places. When running the semanage command in chroot to /mnt/root, I get
>> a file in
>> /mnt/root/etc/selinux/targeted/contexts/files/file_contexts.local, but I
>> do *NOT* get /mnt/root/etc/selinux/targeted/modules/active. The contents
>> of the "active" directory are:
>>
>> [root@localhost active]# ls -al
>> total 9052
>> drwx------. 3 root root    4096 Aug 25 14:35 .
>> drwxr-xr-x. 3 root root      70 Aug 25 14:36 ..
>> -rw-------. 1 root root  249117 Aug 25 14:35 base.pp
>> -rw-------. 1 root root      32 Aug 25 14:35 commit_num
>> -rw-------. 1 root root  290786 Aug 25 14:35 file_contexts
>> -rw-r--r--. 1 root root    6405 Aug 25 14:35 file_contexts.homedirs
>> -rw-------. 1 root root  296417 Aug 25 14:35 file_contexts.template
>> -rw-------. 1 root root    5631 Aug 25 14:35 homedir_template
>> drwx------. 2 root root    8192 Aug 25 14:35 modules
>> -rw-------. 1 root root       0 Aug 25 14:35 netfilter_contexts
>> -rw-r--r--. 1 root root 8380527 Aug 25 14:35 policy.kern
>> -rw-------. 1 root root     106 Aug 25 14:35 seusers.final
>> -rw-------. 1 root root     101 Aug 25 14:35 users_extra
>>
>>
>> The contents of the "files" directory are:
>>
>> [root@localhost files]# ls -al
>> total 304
>> drwxr-xr-x. 2 root root     93 Aug 25 14:36 .
>> drwxr-xr-x. 4 root root   4096 Aug 25 14:36 ..
>> -rw-r--r--. 1 root root 290786 Aug 25 14:36 file_contexts
>> -rw-r--r--. 1 root root   6405 Aug 25 14:36 file_contexts.homedirs
>> -rw-r--r--. 1 root root    120 Aug 25 14:36 file_contexts.local
>> -rw-r--r--. 1 root root    139 Aug 13 02:37 media
>>
>> So, is this a bug? Or, intended behavior due to some condition of
>> running semanage in chroot?
> It sounds like a bug. However, I can't reproduce it.  How did you set up
> your chroot environment, including how are you handling /proc and
> /selinux within the chroot?