Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
If seccomp is set to either tolerant or enabled then connection cannot be established (with seccomp=disabled) it work fine. Switching selinux to permissive mode does not make any difference.
Version-Release number of selected component (if applicable):
libreswan-4.2-1.el9 as well as libreswan-4.4-1.el9
How reproducible:
100%
Steps to Reproduce:
1. Configure client and server as follows:
version 2.0
config setup
plutodebug="all"
logappend=no
plutostderrlog="/tmp/pluto.log"
protostack=netkey
seccomp=tolerant # or enabled
conn test
authby=secret
left=<CLIENT>
right=<SERVER>
keyingtries=1
ikev2=insist
auto=add
2. Start ipsec service on both sides and initiate connection from client:
# ipsec auto --up test
181 "test" #1: initiating IKEv2 connection
181 "test" #1: sent IKE_SA_INIT request
182 "test" #1: sent IKE_AUTH request {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 0.5 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 1 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 2 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 4 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 8 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 16 seconds for response
010 "test" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for response
031 "test" #2: STATE_PARENT_I2: 60 second timeout exceeded after 7 retransmits. Possible authentication failure: no acceptable response to our first encrypted message
002 "test" #1: deleting state (STATE_PARENT_I2) aged 64.043009s and NOT sending notification
003 "test" #2: reschedule pending CHILD SA - the IKE SA #1 is going away
002 "test" #1: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS
Actual results:
See above. The only AVC on the system is already described in BZ#1940843.
Expected results:
Connection can be established and used regardless of seccomp setting.
Additional info:
In the past we were experiencing these issues when some syscalls were missing in allow-lists but it only broke connection when seccomp was set to enabled. Now we see it fails even for seccomp=tolerant and even in permissive selinux mode.
Even though the connection works with 4.6 I think we should not see those SECCOMP audit events on s390x and ppc64le. I did a bit of investigation and getsid syscall SECCOMP can actually be ignored because it is caused by "ipsec whack --seccomp-crashtest" done in the test (they use this particular syscall to test that seccomp works and this whack --seccomp-crashtest option is the test). However, that is not the case of statfs64 syscall. This one needs to be added (I see statfs already included [1]).
Since we ruled out getsid() I am updating the bug summary.
[1] https://github.com/libreswan/libreswan/blob/004ef1508be1a9a6c427f04df3e6647d3380dac7/programs/pluto/pluto_seccomp.c#L160
(In reply to Ondrej Moriš from comment #4)
> I filed https://github.com/libreswan/libreswan/pull/782 to address this
> upstream.
Thank you; as the PR has been merged in 4.8, this bug should be closed once we update the package to that version.
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 (libreswan bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2023:2355
Description of problem: If seccomp is set to either tolerant or enabled then connection cannot be established (with seccomp=disabled) it work fine. Switching selinux to permissive mode does not make any difference. Version-Release number of selected component (if applicable): libreswan-4.2-1.el9 as well as libreswan-4.4-1.el9 How reproducible: 100% Steps to Reproduce: 1. Configure client and server as follows: version 2.0 config setup plutodebug="all" logappend=no plutostderrlog="/tmp/pluto.log" protostack=netkey seccomp=tolerant # or enabled conn test authby=secret left=<CLIENT> right=<SERVER> keyingtries=1 ikev2=insist auto=add 2. Start ipsec service on both sides and initiate connection from client: # ipsec auto --up test 181 "test" #1: initiating IKEv2 connection 181 "test" #1: sent IKE_SA_INIT request 182 "test" #1: sent IKE_AUTH request {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 0.5 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 1 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 2 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 4 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 8 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 16 seconds for response 010 "test" #2: STATE_PARENT_I2: retransmission; will wait 32 seconds for response 031 "test" #2: STATE_PARENT_I2: 60 second timeout exceeded after 7 retransmits. Possible authentication failure: no acceptable response to our first encrypted message 002 "test" #1: deleting state (STATE_PARENT_I2) aged 64.043009s and NOT sending notification 003 "test" #2: reschedule pending CHILD SA - the IKE SA #1 is going away 002 "test" #1: deleting IKE SA but connection is supposed to remain up; schedule EVENT_REVIVE_CONNS Actual results: See above. The only AVC on the system is already described in BZ#1940843. Expected results: Connection can be established and used regardless of seccomp setting. Additional info: In the past we were experiencing these issues when some syscalls were missing in allow-lists but it only broke connection when seccomp was set to enabled. Now we see it fails even for seccomp=tolerant and even in permissive selinux mode.