Bug 1544463 - ipsec service does not work correctly when seccomp filtering is enabled
Summary: ipsec service does not work correctly when seccomp filtering is enabled
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libreswan
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: rc
: 8.3
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
Mirek Jahoda
: 1777474 (view as bug list)
Depends On: 1820206
TreeView+ depends on / blocked
Reported: 2018-02-12 14:54 UTC by Ondrej Moriš
Modified: 2020-11-04 03:18 UTC (History)
5 users (show)

Fixed In Version: 3.32-4
Doc Type: Bug Fix
Doc Text:
.`Libreswan` now works with `seccomp=enabled` on all configurations Prior to this update, the set of allowed syscalls in the `Libreswan` SECCOMP support implementation did not match new usage of RHEL libraries. Consequently, when SECCOMP was enabled in the `ipsec.conf` file, the syscall filtering rejected even syscalls required for the proper functioning of the `pluto` daemon; the daemon was killed, and the `ipsec` service was restarted. With this update, all newly required syscalls have been allowed, and `Libreswan` now works with the `seccomp=enabled` option correctly.
Clone Of:
: 1777474 (view as bug list)
Last Closed: 2020-11-04 03:18:00 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1375750 0 medium CLOSED SECCOMP support for libreswan 2022-01-12 20:07:25 UTC

Internal Links: 1375750

Description Ondrej Moriš 2018-02-12 14:54:01 UTC
Description of problem:

In RHEL-7.5 libreswan comes with SECCOMP support. By default, it is disabled but it can be set to enabled or tolerant setting by seccomp ipsec.conf option. When seccomp is set to disabled no syscall filtering is done. However, when seccomp is set to enabled, it filters syscalls that come from addconn and pluto binaries based on whitelist (ie. everything not explicitly allowed is forbidden, [1,2]). Unfortunately, even for basic use cases whitelist is not complete. We identified at least the following syscalls missing:

type=SECCOMP msg=audit(02/08/2018 13:32:09.021:136) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=13414 comm=pluto sig=SIGSYS arch=x86_64 syscall=clock_gettime compat=0 ip=0x7ffed90416d2 code=kill 

type=SECCOMP msg=audit(02/07/2018 16:47:43.668:176) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=8167 comm=pluto sig=SIGSYS arch=ppc64 syscall=waitpid compat=0 ip=0x3fffacf49028 code=kill 

type=SECCOMP msg=audit(02/07/2018 23:07:08.176:126) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=13042 comm=pluto sig=SIGSYS arch=ppc64le syscall=waitpid compat=0 ip=0x3fff78084e68 code=kill 

type=SECCOMP msg=audit(02/07/2018 17:00:11.249:274) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=2396 comm=pluto sig=SIGSYS arch=s390x syscall=sigreturn compat=0 ip=0x3fffff20830 code=kill 
type=SECCOMP msg=audit(02/07/2018 17:04:43.299:284) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=2396 comm=pluto sig=SIGSYS arch=s390x syscall=socketcall compat=0 ip=0x3fffd3a4ffe code=kill 

When SECCOMP event is triggered pluto is killed and systemd restarts ipsec service (after ~3 minutes when a specific timeout is hit). This makes ipsec service unusable.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:

1. Set seccomp to enabled and configure connection between two hosts.
2. Try to establish connection.
3. Check audit log for SECCOMP events.

Actual results:

SECCOMP events found. Service ipsec restarted. Connection is not established.

Expected results:

No SECCOMP events and correctly established connection.

Additional info:

Please notice that a set of syscalls called when addconn or pluto are executed might differ for different architectures. That is why we see something missing in the whitelist for s390x and not for x86_64, for instance.

[1] programs/pluto/pluto_seccomp.c 
[2] programs/pluto/addconn.c

Comment 20 Paul Wouters 2020-05-21 15:35:14 UTC
upstream test cases:


Comment 22 Paul Wouters 2020-05-26 14:11:58 UTC
*** Bug 1777474 has been marked as a duplicate of this bug. ***

Comment 25 Jaroslav Aster 2020-06-25 14:09:21 UTC
Hi Paul,

it looks like the issue is still there. seccomp doesn't work on non-intel architectures. Switching it back to assigned state.

type=SECCOMP msg=audit(06/25/2020 09:15:05.092:490) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_t:s0 pid=25883 comm=pluto exe=/usr/libexec/ipsec/pluto
sig=SIGSYS arch=aarch64 syscall=ppoll compat=0 ip=0xffff862b866c code=kill

type=SECCOMP msg=audit(06/25/2020 09:38:36.535:513) : auid=unset uid=root gid=root ses=unset subj=system_u:system_r:ipsec_mgmt_t:s0 pid=29865 comm=sh exe=/usr/bin/bash sig=SIGSY
S arch=ppc64le syscall=send compat=0 ip=0x7fffa6c321b4 code=kill

Unfortunately, I do not have results from s390x yet.

Comment 27 Jaroslav Aster 2020-06-25 22:06:47 UTC
Hi Paul,

s390x is ok and works. Anyway, is it ok, that libreswan crashes and coredump is created when seccomp is set to tolerant or enabled?

Comment 38 errata-xmlrpc 2020-11-04 03:18:00 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 (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.


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