Bug 1978397

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.