From: Bond Masuda <bond.masuda@jlbond.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
selinux@tycho.nsa.gov, Steve Lawrence <slawrence@tresys.com>
Subject: Re: question about semanage fcontext and awareness of file_contexts.local file
Date: Tue, 25 Aug 2015 15:46:17 -0700 [thread overview]
Message-ID: <55DCF039.4060001@jlbond.com> (raw)
In-Reply-To: <55DB79DF.4050504@tycho.nsa.gov>
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
next prev parent reply other threads:[~2015-08-25 22:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-17 23:42 question about semanage fcontext and awareness of file_contexts.local file Bond Masuda
2015-08-24 18:15 ` Stephen Smalley
2015-08-24 18:22 ` Bond Masuda
2015-08-24 20:09 ` Stephen Smalley
2015-08-25 22:46 ` Bond Masuda [this message]
2015-08-26 12:55 ` Stephen Smalley
2015-08-27 22:13 ` Bond Masuda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55DCF039.4060001@jlbond.com \
--to=bond.masuda@jlbond.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=slawrence@tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.