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 1544463 - ipsec service does not work correctly when seccomp filtering is enabled
Summary: ipsec service does not work correctly when seccomp filtering is enabled
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libreswan
Version: 8.0
Hardware: All
OS: Linux
medium
high
Target Milestone: rc
: 8.3
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
Mirek Jahoda
URL:
Whiteboard:
: 1777474 (view as bug list)
Depends On: 1820206
Blocks:
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)
Environment:
Last Closed: 2020-11-04 03:18:00 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
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:

x86_64
======
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 

ppc64
=====
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 

ppc64le
=======
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 

s390x
=====
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):

libreswan-3.23-3.el7

How reproducible:

100%

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:

seccomp-01-enabled
seccomp-02-tolerant
seccomp-03-updown
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.

aarch64
-------
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

ppc64le
-------
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.

https://access.redhat.com/errata/RHEA-2020:4722
Note You need to log in before you can comment on or make changes to this bug.