Bug 1280449

Summary: PAM xauth method does not work with pam_sss
Product: Red Hat Enterprise Linux 7 Reporter: Matt Rogers <mrogers>
Component: libreswanAssignee: Paul Wouters <pwouters>
Status: CLOSED ERRATA QA Contact: Ondrej Moriš <omoris>
Severity: high Docs Contact: Mirek Jahoda <mjahoda>
Priority: high    
Version: 7.1CC: omoris, tmraz
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: pluto IKE daemon did not have the CAP_DAC_READ_SEARCH capability Consequence: pam based authentication using pam_sss would fail. Fix: pluto gained the CAP_DAC_READ_SEARCH capability Result: authentication with pam_sss works
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-03 21:21:58 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:
Attachments:
Description Flags
upstream patch none

Description Matt Rogers 2015-11-11 18:33:06 UTC
Created attachment 1092825 [details]
upstream patch

Description of problem:

pluto's current effective|permitted capabilities don't allow a connection to the private pam socket, which is required when using the PAM xauth method and pam_sss.so is in the PAM stack. The auth requests never make it to the sssd pam responder - the stat against the socket in pam_sss' sss_pam_make_request() function fails with EACCES

12:10:04.617248 stat("/var/lib/sss/pipes/private/pam", 0x7fbbbeae7630) = -1 EACCES (Permission denied)

The attached patch adds CAP_DAC_READ_SEARCH to the effective|permitted set and will permit access to the private socket.

Version-Release number of selected component (if applicable):
libreswan-3.15-5.el7_1

How reproducible:
On an IPA client server with pam_sss enabled, configure libreswan as an XAUTH server using xauthby=pam, ie. https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv1_XAUTH

Test a remote client connection, entering an IPA provided user/password. Pluto will report an Authentication failure with no "pam_sss(pluto:auth)" entry in /var/log/secure, nor will there be any sssd logging that indicates a PAM client connection was received. The stat() error can be seen when attaching strace to pluto.

Comment 1 Ondrej Moriš 2016-04-28 18:27:11 UTC
There is already pretty much work acked for 7.3.0, I am wondering how hard is this to fix and to test. Can't we postpone it to 7.4.0?

Comment 6 Ondrej Moriš 2016-08-30 16:35:42 UTC
Successfully verified that xauth=pam works fine with pam_sss (on x86_64).

Old (libreswan-3.12-10.1.el7_1)
===============================
From pluto log:

XAUTH: Sending Username/Password request (XAUTH_R0)
XAUTH: User Amy.qe: Attempting to login
XAUTH: pam authentication being called to authenticate user Amy.qe
XAUTH: pam_authenticate failed with 'Authentication failure'
XAUTH: User Amy.qe: Authentication Failed: Incorrect Username or Password

No pam_sss(pluto:auth) in /var/log/secure.

New (libreswan-3.15-6.el7)
==========================
From pluto log:

XAUTH: Sending Username/Password request (XAUTH_R0)
XAUTH: User Amy.qe: Attempting to login
XAUTH: pam authentication being called to authenticate user Amy.qe
XAUTH: User Amy.qe: Authentication Successful

From /var/log/secure:

pluto: pam_sss(pluto:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost=10.34.88.62 user=Amy.qe

For QE and future test automation, I am using the following:

  * VPN server/client XAUTH with PSK from [1]
  * SSSD & AD from /CoreOS/realmd/Sanity/AD-join-leave-sanity-test

[1] https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv1_XAUTH_with_PSK

Comment 8 errata-xmlrpc 2016-11-03 21:21:58 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-2016-2603.html