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
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssh
Version: 7.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Jakub Jelen
QA Contact: Stanislav Zidek
Depends On:
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)
Last Closed: 2015-11-19 08:02:11 UTC
Target Upstream Version:

Attachments (Terms of Use)

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:


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.


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