]> git.ipfire.org Git - thirdparty/systemd.git/commit - src/nspawn/nspawn-seccomp.c
seccomp: tighten checking of seccomp filter creation 10158/head
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Thu, 20 Sep 2018 12:19:41 +0000 (14:19 +0200)
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Mon, 24 Sep 2018 15:21:09 +0000 (17:21 +0200)
commit7e86bd73a47f2b8dd3d9a743e69fb0117f450ad8
tree89033936668e8ca342b36c0ae2f59965cf01411d
parentb54f36c604472ffe08830ec4306fa2885b4a5424
seccomp: tighten checking of seccomp filter creation

In seccomp code, the code is changed to propagate errors which are about
anything other than unknown/unimplemented syscalls. I *think* such errors
should not happen in normal usage, but so far we would summarilly ignore all
errors, so that part is uncertain. If it turns out that other errors occur and
should be ignored, this should be added later.

In nspawn, we would count the number of added filters, but didn't use this for
anything. Drop that part.

The comments suggested that seccomp_add_syscall_filter_item() returned negative
if the syscall is unknown, but this wasn't true: it returns 0.

The error at this point can only be if the syscall was known but couldn't be
added. If the error comes from our internal whitelist in nspawn, treat this as
error, because it means that our internal table is wrong. If the error comes
from user arguments, warn and ignore. (If some syscall is not known at current
architecture, it is still silently ignored.)
src/nspawn/nspawn-seccomp.c
src/shared/seccomp-util.c