Red Hat Bugzilla – Bug 1278063
Unable to authenticate with PAM for IKEv1 XAUTH
Last modified: 2016-11-03 17:21:54 EDT
Description of problem: I am unable to authenticate when setting xauthby=pam. Version-Release number of selected component (if applicable): libreswan-3.15-5.el7_1.x86_64 Additional info: I was informed by bleve on IRC that this was fixed in 3.16rc1 via: https://github.com/libreswan/libreswan/commit/f62484cec50e0fd53f9fcdf5491e21b4fc522940 So, it seems that a backport would be necessary (or a will-not-fix).
I think it should go into 7.3 with the recertification
This issue is really tricky. Basically, I considered this bug to be verified because of RHBZ#1280449#c6 - ie. when using xauthby=pam and pam_sss in PAM stack it works just fine. However, when pam_unix is used instead of pam_sss it does not work. There seems not to be a way to debug the problem in PAM since pam_unix ignores debug and audit parameters (or journald is just throwing them away). Here is my configuration: SERVER ====== # cat /etc/ipsec.conf version 2.0 config setup plutodebug="lifecycle" plutostderrlog="/var/log/pluto.log" protostack=netkey nat_traversal=yes virtual_private= oe=off conn xauth-psk authby=secret pfs=no auto=add rekey=no left=10.34.88.24 leftid=@test right=10.34.88.15 leftxauthserver=yes rightxauthclient=yes xauthby=pam ike-frag=yes ikev2=no # cat /etc/ipsec.secrets : PSK "ExampleSecret" CLIENT ====== # cat /etc/ipsec.conf version 2.0 config setup plutodebug="lifecycle" plutostderrlog="/var/log/pluto.log" protostack=netkey nat_traversal=yes virtual_private= oe=off conn xauth-psk authby=secret left=10.34.88.15 leftxauthclient=yes leftxauthusername=Amy@ad.baseos.qe # leftxauthusername=testuser right=10.34.88.24 rightxauthserver=yes rekey=no auto=add ike_frag=yes rightid=@test ikev2=no # cat /etc/ipsec.secrets : PSK "ExampleSecret" @Amy@ad.baseos.qe: XAUTH "Pass2012!" @testuser: XAUTH "redhat" Amy is authenticated via pam_sss: CLIENT# ipsec auto --up xauth-psk 002 "xauth-psk" #1: initiating Main Mode 104 "xauth-psk" #1: STATE_MAIN_I1: initiate 003 "xauth-psk" #1: received Vendor ID payload [Dead Peer Detection] 003 "xauth-psk" #1: received Vendor ID payload [FRAGMENTATION] 003 "xauth-psk" #1: received Vendor ID payload [XAUTH] 003 "xauth-psk" #1: received Vendor ID payload [RFC 3947] 002 "xauth-psk" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal) 002 "xauth-psk" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 106 "xauth-psk" #1: STATE_MAIN_I2: sent MI2, expecting MR2 003 "xauth-psk" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected 002 "xauth-psk" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 108 "xauth-psk" #1: STATE_MAIN_I3: sent MI3, expecting MR3 002 "xauth-psk" #1: Main mode peer ID is ID_FQDN: '@test' 002 "xauth-psk" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 004 "xauth-psk" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP1536} 002 "xauth-psk" #1: XAUTH: Answering XAUTH challenge with user='Amy@ad.baseos.qe' 002 "xauth-psk" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1 004 "xauth-psk" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set 003 "xauth-psk" #1: discarding duplicate packet; already STATE_XAUTH_I1 010 "xauth-psk" #1: STATE_XAUTH_I1: retransmission; will wait 500ms for response 002 "xauth-psk" #1: XAUTH: Successfully Authenticated 002 "xauth-psk" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1 004 "xauth-psk" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set 002 "xauth-psk" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+DONT_REKEY+UP+XAUTH+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW {using isakmp#1 msgid:8a9c157c proposal=defaults pfsgroup=OAKLEY_GROUP_MODP1536} 117 "xauth-psk" #2: STATE_QUICK_I1: initiate 002 "xauth-psk" #2: Warning: XAUTH username changed from '' to '' 002 "xauth-psk" #2: Warning: XAUTH username changed from '' to '' 002 "xauth-psk" #2: Warning: XAUTH username changed from '' to '' 002 "xauth-psk" #2: transition from state STATE_QUICK_I1 to state STATE_QUICK_I2 004 "xauth-psk" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0x93287e93 <0x72d580d1 xfrm=AES_128-HMAC_SHA1 NATOA=none NATD=none DPD=passive XAUTHuser=Amy@ad.baseos.qe} SERVER# tail /var/log/secure Sep 16 14:34:17 sheep-24 pluto: pam_sss(pluto:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost=10.34.88.15 user=Amy@ad.baseos.qe Sep 16 14:34:17 sheep-24 sssd[be[ad.baseos.qe]]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode. SERVER# cat /var/log/pluto.log ... Sep 16 14:34:16: XAUTH: User Amy@ad.baseos.qe: Attempting to login Sep 16 14:34:16: XAUTH: pam authentication being called to authenticate user Amy@ad.baseos.qe Sep 16 14:34:17: XAUTH: User Amy@ad.baseos.qe: Authentication Successful But testuser is authenticated via pam_unix: CLIENT# ipsec auto --up xauth-psk 002 "xauth-psk" #1: initiating Main Mode 104 "xauth-psk" #1: STATE_MAIN_I1: initiate 003 "xauth-psk" #1: received Vendor ID payload [Dead Peer Detection] 003 "xauth-psk" #1: received Vendor ID payload [FRAGMENTATION] 003 "xauth-psk" #1: received Vendor ID payload [XAUTH] 003 "xauth-psk" #1: received Vendor ID payload [RFC 3947] 002 "xauth-psk" #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal) 002 "xauth-psk" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2 106 "xauth-psk" #1: STATE_MAIN_I2: sent MI2, expecting MR2 003 "xauth-psk" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal) sender port 500: no NAT detected 002 "xauth-psk" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3 108 "xauth-psk" #1: STATE_MAIN_I3: sent MI3, expecting MR3 002 "xauth-psk" #1: Main mode peer ID is ID_FQDN: '@test' 002 "xauth-psk" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4 004 "xauth-psk" #1: STATE_MAIN_I4: ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha group=MODP1536} 002 "xauth-psk" #1: XAUTH: Answering XAUTH challenge with user='testuser' 002 "xauth-psk" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1 004 "xauth-psk" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set 003 "xauth-psk" #1: discarding duplicate packet; already STATE_XAUTH_I1 010 "xauth-psk" #1: STATE_XAUTH_I1: retransmission; will wait 500ms for response 003 "xauth-psk" #1: discarding duplicate packet; already STATE_XAUTH_I1 010 "xauth-psk" #1: STATE_XAUTH_I1: retransmission; will wait 1000ms for response 036 "xauth-psk" #1: encountered fatal error in state STATE_XAUTH_I1 SERVER# tail /var/log/secure Sep 16 14:36:28 sheep-24 unix_chkpwd[17287]: check pass; user unknown Sep 16 14:36:28 sheep-24 unix_chkpwd[17288]: check pass; user unknown Sep 16 14:36:28 sheep-24 unix_chkpwd[17288]: password check failed for user (testuser) Sep 16 14:36:28 sheep-24 pluto: pam_unix(pluto:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=10.34.88.15 user=testuser SERVER# cat /var/log/pluto.log ... Sep 16 14:36:28: XAUTH: User testuser: Attempting to login Sep 16 14:36:28: XAUTH: pam authentication being called to authenticate user testuser Sep 16 14:36:30: IKEv2 : pam_authenticate failed with 'Authentication failure' Sep 16 14:36:30: XAUTH: User testuser: Authentication Failed: Incorrect Username or Password Account testuser is perfectly fine, eg. it can be used to ssh login: CLIENT# ssh testuser@sheep-24.lab.eng.brq.redhat.com whoami testuser@sheep-24.lab.eng.brq.redhat.com's password: testuser I have tested with libreswan-3.15-8.el7, libreswan-3.15-6.el7 and libreswan-3.12-11.el7. Any ideas?
If the authentication works with pam_sss and does not with pam_unix and the authenticating process runs with uid 0, it is most probably a SELinux issue. Could you try running it in permissive mode?
THANKS! It really is selinux-policy issue: # ausearch -ts 15:13:38 -m avc -sv no ---- time->Fri Sep 16 15:13:59 2016 type=SYSCALL msg=audit(1474031639.414:1174): arch=c000003e syscall=2 success=no exit=-13 a0=7fd6344b9453 a1=80000 a2=1b6 a3=24 items=0 ppid=17116 pid=17440 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0 key=(null) type=AVC msg=audit(1474031639.414:1174): avc: denied { dac_read_search } for pid=17440 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability ---- time->Fri Sep 16 15:13:59 2016 type=SYSCALL msg=audit(1474031639.417:1175): arch=c000003e syscall=2 success=no exit=-13 a0=7fde9eaea453 a1=80000 a2=1b6 a3=24 items=0 ppid=17116 pid=17441 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0 key=(null) type=AVC msg=audit(1474031639.417:1175): avc: denied { dac_read_search } for pid=17441 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability # ausearch -ts recent -m avc -sv no | audit2allow #============= chkpwd_t ============== allow chkpwd_t self:capability dac_read_search; In permissive mode it works just fine.
I thought it was a capabilities issue? The upstream patch is this: commit 6d909f1963dfecfcc08f114d6bd555b7fcf9184b Author: Matt Rogers <mrogers@redhat.com> Date: Wed Nov 11 12:34:56 2015 -0500 Add CAP_DAC_READ_SEARCH to the added capabilities CAP_DAC_READ_SEARCH was only in the bounding set. Without it in the added set, pam authentication with a stacked module that accesses a priviledged socket (i.e pam_sss) will fail.
For pam_sss it was capability issues, however I am not sure what is the problem in pam_unix. It must be something else since CAP_DAC_READ_SEARCH capability (patch) is just there. Clearly, unix_chkpwd is trying to read something: time->Sat Sep 17 12:06:56 2016 type=PATH msg=audit(1474106816.540:2362): item=0 name="/etc/shadow" inode=67668197 dev=fd:00 mode=0100000 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:shadow_t:s0 objtype=NORMAL type=CWD msg=audit(1474106816.540:2362): cwd="/run/pluto" type=SYSCALL msg=audit(1474106816.540:2362): arch=c000003e syscall=2 success=no exit=-13 a0=7fb186b7c453 a1=80000 a2=1b6 a3=24 items=1 ppid=23533 pid=23668 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="unix_chkpwd" exe="/usr/sbin/unix_chkpwd" subj=system_u:system_r:chkpwd_t:s0 key=(null) type=AVC msg=audit(1474106816.540:2362): avc: denied { dac_read_search } for pid=23668 comm="unix_chkpwd" capability=2 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=capability I would say it is a bug in selinux-policy, Paul...? I just reported RHBZ#1376991 and let's see what our selinux folks think about this.
(In reply to Ondrej Moriš from comment #9) Actually from the AVC above it is clear that the SELinux blocks the capability for the chkpwd_t domain. Normally this capability does not come into play as dac override capability is assigned to the unix_chkpwd.
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