Bug 1125110

Summary:	pam_namespace usage is not consistent across system-wide PAM configuration
Product:	Red Hat Enterprise Linux 7	Reporter:	(GalaxyMaster) <gm.outside+redhat>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED ERRATA	QA Contact:	Stanislav Zidek <szidek>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	7.2	CC:	jjelen, ksrot, plautrba, tmraz
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	openssh-6.6.1p1-13.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1250069 (view as bug list)		Environment:
Last Closed:	2015-11-19 08:02:11 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:

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.

https://rhn.redhat.com/errata/RHSA-2015-2088.html