RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1125110 - pam_namespace usage is not consistent across system-wide PAM configuration
Summary: pam_namespace usage is not consistent across system-wide PAM configuration
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.2
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stanislav Zidek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-31 04:43 UTC by (GalaxyMaster)
Modified: 2016-02-09 08:27 UTC (History)
4 users (show)

Fixed In Version: openssh-6.6.1p1-13.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1250069 (view as bug list)
Environment:
Last Closed: 2015-11-19 08:02:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2088 0 normal SHIPPED_LIVE Moderate: openssh security, bug fix, and enhancement update 2015-11-19 08:38:51 UTC

Description (GalaxyMaster) 2014-07-31 04:43:45 UTC
Description of problem:

The default configuration of the PAM stack is not using pam_namespace consistently and leads to multiple issues when there are different entry points to get a running process under a user account.  The following PAM configuration use the pam_namespace module:

login
newrole
remote

So, if the polyinstantiation is enabled on a system, a user that logs in on the console will get their defined directories polyinstantiated, while a user logging in via ssh will not.  The same goes for newrole/runuser/su - with newrole the polyinstantiation will work, but with runuser/su it won't.  Also a major issue is with crond which is launching processes under user - these processes won't see the polyinstantiated directories, hence they won't be able to work with the files/directories there.

How reproducible:


Steps to Reproduce:
1. echo "/tmp /tmp-inst level root,adm" /etc/security/namespace.d/local.conf
2. setsebool -P polyinstantiation_enabled on
3. mkdir -m0 /tmp-inst
4. restorecon /tmp-inst

[at this point we configured the polyinstantiation of /tmp for users]

5. (on a console, e.g. tty2) login as a non-privileged user, check the /tmp directory (should be empty), and touch /tmp/test-file
6. login as the same user via ssh and check the /tmp directory, there will be no /tmp/test-file since the /tmp directory is not polyinstantiated.

Actual results:

The polyinstantiation of the configured directories is performed for the user logged in on the console, but is not performed for the same user logged in via ssh.

Expected results:

all switches under the user account with the polyinstantiation configured and enabled should see the same filesystem layout with directories polyinstantiated according to the configuration.

Additional info:

This behaviour makes it almost impossible to use such a nice feature as polyinstantiation out of the box and heavy tweaking of the distribution supplied PAM configuration is required.  This increases maintenance costs and makes this feature to be non-viable to use.  It would be very nice if RHEL provided proper support for the documented feature and not a partially working solution like it is now.

Comment 2 (GalaxyMaster) 2014-07-31 07:16:37 UTC
It is also worth to mention that pam_namespace's documentation is poor.  For example, instead of asking the user to create the instance parent directory and chmod'ing it to 0, /etc/security/namespace.conf could be tweaked to use 'level:create=0,root,root' instead of just 'level' -- this way pam_namespace would take care of creating the instance parent directory itself.

Comment 3 Tomas Mraz 2014-08-04 08:25:52 UTC
This would have to be reported against all the packages that ship the pam configuration without the pam_namespace.

Comment 4 Tomas Mraz 2014-08-05 09:38:08 UTC
Reassigning to openssh, but it should be reported also against the other packages that miss pam_namespace call.

Comment 5 (GalaxyMaster) 2014-08-05 10:11:11 UTC
Actually it could have been fixed in the pam package (e.g. by moving pam_namespace into system-auth - this would have enabled pam_namespace for everything).  However, this could break su (if it's a SELinux enabled system), so a fix for su would have been required too.  Personally, I'd go this route since it's more systematic.

Comment 7 Jakub Jelen 2015-03-31 12:27:14 UTC
After discussion with Tomas it seems reasonable to add this module into pam.d in this way and use for rhel-7.2.

But it doesn't change the thing that your configuration is wrong. If I try your proposed reproducer, I'm running into 
> pam_namespace(sshd:session): Error creating or accessing instance parent , No such file or directory
You need at least specify slash after /tmp/



--- /etc/pam.d/sshd.orig	2015-03-31 13:40:35.333000000 +0200
+++ /etc/pam.d/sshd	2015-03-31 13:41:08.020000000 +0200
@@ -10,6 +10,7 @@
 session    required     pam_loginuid.so
 # pam_selinux.so open should only be followed by sessions to be executed in the user context
 session    required     pam_selinux.so open env_params
+session    required     pam_namespace.so
 session    optional     pam_keyinit.so force revoke
 session    include      password-auth
 session    include      postlogin

Comment 8 (GalaxyMaster) 2015-04-01 06:08:12 UTC
Well, after reviewing the reproduction steps and trying it on a VM I found the following error in step 1:

1. echo "/tmp /tmp-inst level root,adm" /etc/security/namespace.d/local.conf

this line meant to be:

1. echo "/tmp /tmp-inst/ level root,adm" > /etc/security/namespace.d/local.conf

So, the ending slash should have been put _after_ instance parent directory (the error message from pam_namespace is a bit cryptic, but what pam_namespace is doing behind the scenes is concatenating the parent directory with the computed user name and level to form a directory it is going to mount).  Another bug was that somehow the redirection character was lost when I submitted the original request.

I've just double checked that the reproducer works with the above adjustments.

Comment 15 errata-xmlrpc 2015-11-19 08:02:11 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, 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://rhn.redhat.com/errata/RHSA-2015-2088.html


Note You need to log in before you can comment on or make changes to this bug.