RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1278063 - Unable to authenticate with PAM for IKEv1 XAUTH
Summary: Unable to authenticate with PAM for IKEv1 XAUTH
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.2
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-11-04 16:06 UTC by ToBeReplaced
Modified: 2016-11-03 21:21 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: pam_acct_mgmt was not properly set Consequence: pam_unix authentication did not work Fix: set pam_acct_mgmt properly Result: pam_unix authentication works.
Clone Of:
Environment:
Last Closed: 2016-11-03 21:21:54 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1376991 0 medium CLOSED unix_chkpwd is missing dac_read_search capability 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2016:2603 0 normal SHIPPED_LIVE Moderate: libreswan security and bug fix update 2016-11-03 12:13:02 UTC

Internal Links: 1376991

Description ToBeReplaced 2015-11-04 16:06:01 UTC 
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).
Comment 2 Paul Wouters 2015-11-05 08:43:39 UTC 
I think it should go into 7.3 with the recertification
Comment 5 Ondrej Moriš 2016-09-16 12:42:50 UTC 
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.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.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.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.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.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.qe: Attempting to login
Sep 16 14:34:16: XAUTH: pam authentication being called to authenticate user Amy.qe
Sep 16 14:34:17: XAUTH: User Amy.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.eng.brq.redhat.com whoami
testuser.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?
Comment 6 Tomas Mraz 2016-09-16 12:54:43 UTC 
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?
Comment 7 Ondrej Moriš 2016-09-16 13:15:07 UTC 
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.
Comment 8 Paul Wouters 2016-09-16 15:00:50 UTC 
I thought it was a capabilities issue? The upstream patch is this:

commit 6d909f1963dfecfcc08f114d6bd555b7fcf9184b
Author: Matt Rogers <mrogers>
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.
Comment 9 Ondrej Moriš 2016-09-17 10:29:13 UTC 
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.
Comment 11 Tomas Mraz 2016-09-19 10:19:58 UTC 
(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.
Comment 13 errata-xmlrpc 2016-11-03 21:21:54 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
Note You need to log in before you can comment on or make changes to this bug.