Bug 2099194

Summary: Files in /tmp-inst/ directory (and sub-dirs) are not labeled correctly
Product: Red Hat Enterprise Linux 9 Reporter: Renaud Métrich <rmetrich>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Milos Malik <mmalik>
Severity: medium Docs Contact:
Priority: medium    
Version: 9.0CC: lvrabec, mmalik
Target Milestone: rcKeywords: AutoVerified, Triaged
Target Release: 9.2Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-38.1.15-1.el9 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-07 08:52:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2091979    

Description Renaud Métrich 2022-06-20 09:52:10 UTC
Description of problem:

This is a sub-BZ of BZ #2091979.
By default /tmp-inst is the root directory for poly-instantiation. Files under this directory have to be labeled with "<<None>>", similarly to regular /tmp.
But it's currently not the case, files get broken label "default_t" when using *restorecon*/*matchpathcon*:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# matchpathcon /tmp-inst/foo
/tmp-inst/foo	system_u:object_r:default_t:s0
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

We need the following rule to be added in the policy:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
/tmp-inst/.*                                       all files          <<None>>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

*Additionally*, files in /var/tmp/tmp-inst have to be labeled with "<<None>>" as well. This is the case but because of the inheritance on "/var/tmp", not on "/var/tmp/tmp-inst":
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
/var/tmp/.*                                        all files          <<None>>
/var/tmp/tmp-inst                                  directory          system_u:object_r:tmp_t:s0 
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

For clarity, I would recommend adding a rule on "/var/tmp/tmp-inst/.*" (which doesn't exist):
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
/var/tmp/tmp-inst/.*                               all files          <<None>>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

This would make things more clear when administrators want to setup a different path for poly-instantiation than /var/tmp/tmp-inst, which has to be done through creating an equivalency context.

Version-Release number of selected component (if applicable):

selinux-policy-34.1.29-1.el9_0.noarch

How reproducible:

Always

Steps to Reproduce:
1. Enable poly-instantiation for users (in /etc/security/namespace.conf)
2. Start pam_nameservice service to create the directories
3. Log in as a user
4. Check restorecon on the user

  # restorecon -Frnv /tmp-inst

Actual results:

# restorecon -Frnv /tmp-inst
Would relabel /tmp-inst/system_u:object_r:tmp_t:s0-s0:c0.c1023_user1/ssh-XXXXZqdMQd from unconfined_u:object_r:default_t:s0 to system_u:object_r:default_t:s0
Would relabel /tmp-inst/system_u:object_r:tmp_t:s0-s0:c0.c1023_user1/ssh-XXXXZqdMQd/agent.1024 from unconfined_u:object_r:default_t:s0 to system_u:object_r:default_t:s0

Expected results:

No relabel, stick to "<<None>>"

Comment 1 Zdenek Pytela 2023-02-08 09:48:14 UTC
Commit to backport:
f1458a62d Add none file context for polyinstantiated tmp dirs

Comment 13 errata-xmlrpc 2023-11-07 08:52:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6617