Bug 803846

+++ This bug was initially created as a clone of Bug #678577 +++

Description of problem:
SELinux context of my directory depends on the order in which I add "semanage fcontext" rules. I believe it should not depend on that (it should use best match instead).

# mkdir /shared/samba -p
# semanage fcontext -a -t public_content_t "/shared(/.*)?"
# semanage fcontext -a -t samba_share_t "/shared/samba(/.*)?"
# restorecon -FvvR /shared/
restorecon reset /shared context unconfined_u:object_r:default_t:s0->system_u:object_r:public_content_t:s0
restorecon reset /shared/samba context unconfined_u:object_r:default_t:s0->system_u:object_r:samba_share_t:s0
#
# semanage fcontext -d "/shared(/.*)?"
# semanage fcontext -d "/shared/samba(/.*)?"
# semanage fcontext -l | grep /shared
# restorecon -FvvR /shared/
restorecon reset /shared context system_u:object_r:public_content_t:s0->system_u:object_r:default_t:s0
restorecon reset /shared/samba context system_u:object_r:samba_share_t:s0->system_u:object_r:default_t:s0
#
# # add rules in reverse order
# semanage fcontext -a -t samba_share_t "/shared/samba(/.*)?"
# semanage fcontext -a -t public_content_t "/shared(/.*)?"
# restorecon -FvvR /shared/
restorecon reset /shared context system_u:object_r:default_t:s0->system_u:object_r:public_content_t:s0
restorecon reset /shared/samba context system_u:object_r:default_t:s0->system_u:object_r:public_content_t:s0
# # wrong context on /shared/samba

Version-Release number of selected component (if applicable):
policycoreutils-2.0.83-33.10.fc14.x86_64
libselinux-2.0.96-6.fc14.1.x86_64
checkpolicy-2.0.23-2.fc14.x86_64
polkit-desktop-policy-0.98-4.fc14.noarch
selinux-policy-3.9.7-29.fc14.noarch
libselinux-python-2.0.96-6.fc14.1.x86_64
policycoreutils-python-2.0.83-33.10.fc14.x86_64
selinux-policy-targeted-3.9.7-29.fc14.noarch
libselinux-utils-2.0.96-6.fc14.1.x86_64

How reproducible:
always

Steps to Reproduce:
1. run the code in the description
  
Actual results:
final directory context depends on the order in which the rules were added

Expected results:
final directory context is determined by best matching rule

Additional info:
Also affects RHEL 6.0

--- Additional comment from dwalsh on 2011-02-18 09:50:39 EST ---

Is this something we want to fix?  Shouldn't file context local use the same algorythm file_context uses?

--- Additional comment from sds.gov on 2011-02-18 09:58:28 EST ---

Background reading:
http://marc.info/?l=selinux&m=121154579506667&w=2

You'd need to take it up as an upstream selinux issue, but there is no fully general way to decide "best matching rules" so long as we support arbitrary regexes in the pathname fields.  We'd have to go to a more restricted syntax (e.g. file name globs) for more determinism.

--- Additional comment from sds.gov on 2011-02-18 10:04:23 EST ---

Oh, and just to clarify:  last matching rule wins has always been the documented behavior for setfiles.

--- Additional comment from kparal on 2011-02-18 10:28:11 EST ---

As for the "last matching rule" - if it is clearly documented this way, well, alright (nothing's perfect, I guess). But how should I know which rule was defined last? "semanage fcontext -l" can't be used for that:

# semanage fcontext -a -t samba_share_t "/shared/samba(/.*)?"
# ...months pass by...
# semanage fcontext -a -t public_content_t "/shared(/.*)?"
# ...months pass by...
# semanage fcontext -l | grep /shared
/shared(/.*)?                                      all files          system_u:object_r:public_content_t:s0 
/shared/samba(/.*)?                                all files          system_u:object_r:samba_share_t:s0 

As a system administrator I would be confused because from the "semanage fcontext -l" output everything seems ok (but it's not).

--- Additional comment from sds.gov on 2011-02-18 11:07:56 EST ---

I'm guessing that semanage fcontext is just walking a hash table rather than dumping the file contents.

I agree that we can do better here, but we have to be careful to avoid breaking existing setups.  It would be simple enough to change libsemanage to invoke semanage_fc_sort on the file_contexts.local contents before writing them to the file.  This is already done for file_contexts in order to provide sane ordering among entries in different policy modules, and uses a set of heuristics.  However, if any admin were relying on the prior behavior, this could switch his labeling.

--- Additional comment from sds.gov on 2011-02-18 11:14:36 EST ---

I guess what we could do is to introduce yet another /etc/selinux/semanage.conf option to control whether or not file_contexts.local gets sorted (default to off, to match current behavior), and then change libsemanage to apply semanage_fc_sort if this option is enabled.  Then Dan could turn it on in Fedora and/or RHEL and if someone squawks, they can turn it off in their local config.

--- Additional comment from edgar.hoch.de on 2011-11-29 12:42:51 EST ---

Is there something new or changed in Fedora 15 or 16 about this problem?

I think that it would be the best if
- more specific rules should match before less specific,
  e.g. if there exists a rule for /a/b(/.*) and one for /a/b/c(/.*), then the last one should be applied
- local added rules should overwrite system rules.

--- Additional comment from dwalsh on 2011-11-29 14:49:59 EST ---

That is the way it is supposed to work.

--- Additional comment from sds.gov on 2011-11-29 14:59:13 EST ---

Original bug was that file_contexts.local is not sorted by semanage_fc_sort, unlike file_contexts (i.e. the module .fc files).  So you can get a different result depending on the order in which you invoke semanage fcontext -a commands. I think that is still true; I haven't seen a patch for that.

--- Additional comment from dwalsh on 2011-11-29 15:04:39 EST ---

Me either.  Moving this to F16.