Bug 678577

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

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.

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

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).

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.

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.

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.

That is the way it is supposed to work.

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.

Me either.  Moving this to F16.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

The problem described in comment #7 still exists in Fedora 23.

Example:

Local SELinux-fcontext:

/fs(/[^/]*)                                        symbolic link      system_u:object_r:mnt_t:s0 
/fs(/[^/]*)?                                       directory          system_u:object_r:mnt_t:s0 
/fs/.*/lost\+found                                 directory          system_u:object_r:lost_found_t:s0 
/fs/.*/lost\+found/.*                              all files          <<None>>

Result:
# matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	system_u:object_r:lost_found_t:s0
/fs/ftp-daten/myftp	system_u:object_r:default_t:s0


Adding following rule
/]*/.*                                       all files          <<None>>

results in
# matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	<<none>>
/fs/ftp-daten/myftp	<<none>>

See: lost+found have wrong type!


Removing the rule above and adding the SELinux Local fcontext Equivalence
/fs/ftp-daten(/.*)? = /var/ftp

is ignored:
# matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	system_u:object_r:lost_found_t:s0
/fs/ftp-daten/myftp	system_u:object_r:default_t:s0

See: /fs/ftp-daten/myftp has wrong type!

Additional note to comment #13:

When I remove the all rules listed above
and first add the rule
/fs/[^/]*/.*                                       all files          <<None>>

and then add the other rules back, then it does not overwrite the other rules.
In the example above, lost+found will have the correct label.

Please note: There is a spelling error in comment #13. The added rule in the second example should the same as in this comment.

The rule listed in comment #13 is intended to be a fallback rule (by myself), to prevent all files in /fs/* to be labeled as default_t it there is no other rule that matches.

To realize this behavior, it should have the lowest precedence.

On the other hand, there are rules like that for directory lost+found or files aquota.user and aquota.group that should be defined relative to the top of every file system instead of root "/", because if they exist they are always on the first directory level of the file system. Rules for such special files should have highest precedence over other rules.

Currently we cannot define such a precedence (priority) of a rule, and we cannot define rules relative to the top of a file system. It may be worth of thinking about such an enhancement of selinux fcontext rules.

But the main problems described in the previous comments results from the dependency of rule order instead of the selection of the most specific rule, independent of the order the rules were added.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The problem still exists on Fedora 25. Please reopen it!

kernel-4.8.14-300.fc25.x86_64
selinux-policy-3.13.1-225.3.fc25.noarch

I have retested my test case of comment #13 on Fedora 25.

I have a clean installed Fedora 25 test system (the following rule was not added by me):

# LANG=C semanage fcontext -l -C
SELinux fcontext                                   type               Context

/usr/share/dnfdaemon/dnfdaemon-system              all files          system_u:object_r:rpm_exec_t:s0 


Then I have added these rules:

# semanage fcontext -a -f a -t '<<none>>' '/fs/[^/]*/.*'
# semanage fcontext -a -f l -t 'mnt_t' '/fs(/[^/]*)'
# semanage fcontext -a -f d -t 'mnt_t' '/fs(/[^/]*)?'
# semanage fcontext -a -f d -t 'lost_found_t' '/fs/.*/lost\+found'
# semanage fcontext -a -f a -t 'lost_found_t' '/fs/.*/lost\+found/.*'

# LANG=C semanage fcontext -l -C
SELinux fcontext                                   type               Context

/fs(/[^/]*)                                        symbolic link      system_u:object_r:mnt_t:s0 
/fs(/[^/]*)?                                       directory          system_u:object_r:mnt_t:s0 
/fs/.*/lost\+found                                 directory          system_u:object_r:lost_found_t:s0 
/fs/.*/lost\+found/.*                              all files          system_u:object_r:lost_found_t:s0 
/fs/[^/]*/.*                                       all files          <<None>>
/usr/share/dnfdaemon/dnfdaemon-system              all files          system_u:object_r:rpm_exec_t:s0 

# LANG=C matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	system_u:object_r:lost_found_t:s0
/fs/ftp-daten/myftp	<<none>>

In this case, the labels are right.


To test, I have removed the first rule and added it again:

# semanage fcontext -d -f a -t '<<none>>' '/fs/[^/]*/.*'

# LANG=C matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	system_u:object_r:lost_found_t:s0
/fs/ftp-daten/myftp	system_u:object_r:default_t:s0

This is still correct.

# semanage fcontext -a -f a -t '<<none>>' '/fs/[^/]*/.*'

# LANG=C semanage fcontext -l -C
SELinux fcontext                                   type               Context

/fs(/[^/]*)                                        symbolic link      system_u:object_r:mnt_t:s0 
/fs(/[^/]*)?                                       directory          system_u:object_r:mnt_t:s0 
/fs/.*/lost\+found                                 directory          system_u:object_r:lost_found_t:s0 
/fs/.*/lost\+found/.*                              all files          system_u:object_r:lost_found_t:s0 
/fs/[^/]*/.*                                       all files          <<None>>
/usr/share/dnfdaemon/dnfdaemon-system              all files          system_u:object_r:rpm_exec_t:s0 

# LANG=C matchpathcon /fs /fs/ftp-daten /fs/ftp-daten/lost+found /fs/ftp-daten/myftp
/fs	system_u:object_r:mnt_t:s0
/fs/ftp-daten	system_u:object_r:mnt_t:s0
/fs/ftp-daten/lost+found	<<none>>
/fs/ftp-daten/myftp	<<none>>

This is WRONG!
/fs/ftp-daten/lost+found should have fcontext type lost_found_t, not <<none>> !


So the order of the rules added are still relevant, but the rules should be applied by best match, not by order in the list!

Reopening. But we still don't have a patch which would fix/change it.

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

I see this in centos 7.3 with:

libselinux-2.5-6.el7.x86_64
selinux-policy-3.13.1-166.el7_4.4.noarch
selinux-policy-targeted-3.13.1-166.el7_4.4.noarch

if I have something like:

$ semanage fcontext -lC
...
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/db(/.*)?  all files          system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/locks(/.*)? all files          system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?           all files          system_u:object_r:httpd_sys_content_t:s0

then:
$ /__.aLocalStorages/0/0-SUBVERSIONs/myRepo/locks will *NOT* get "httpd_sys_rw_content_t"
but I put/add them so they would be:

/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?           all files          system_u:object_r:httpd_sys_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/db(/.*)?  all files          system_u:object_r:httpd_sys_rw_content_t:s0
/__.aLocalStorages/0/0-SUBVERSIONs(/.*)?/locks(/.*)? all files          system_u:object_r:httpd_sys_rw_content_t:s0

then yes, /__.aLocalStorages/0/0-SUBVERSIONs/myRepo/locks will get "httpd_sys_rw_content_t"

And yes, from an admin's perspective I'd think, expect that most targeting rule wins and not the order of the rules in the list.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.