Bug 1280449 - PAM xauth method does not work with pam_sss
PAM xauth method does not work with pam_sss
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan (Show other bugs)
7.1
All Linux
high Severity high
: rc
: ---
Assigned To: Paul Wouters
Ondrej Moriš
Mirek Jahoda
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-11 13:33 EST by Matt Rogers
Modified: 2016-11-03 17:21 EDT (History)
2 users (show)

See Also:
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 17:21:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
upstream patch (881 bytes, patch)
2015-11-11 13:33 EST, Matt Rogers
no flags Details | Diff

  None (edit)
Description Matt Rogers 2015-11-11 13:33:06 EST
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 14:27:11 EDT
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 12:35:42 EDT
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@ad.baseos.qe: Attempting to login
XAUTH: pam authentication being called to authenticate user Amy@ad.baseos.qe
XAUTH: pam_authenticate failed with 'Authentication failure'
XAUTH: User Amy@ad.baseos.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@ad.baseos.qe: Attempting to login
XAUTH: pam authentication being called to authenticate user Amy@ad.baseos.qe
XAUTH: User Amy@ad.baseos.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@ad.baseos.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 17:21:58 EDT
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

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