Stéphane Graber [Tue, 8 Oct 2019 19:24:10 +0000 (15:24 -0400)]
build: ship seccomp-syscalls.h
Without this, anything which includes "seccomp.h" will fail when using a build version of libseccomp.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com> Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: tweaked the subject line] Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Sun, 29 Sep 2019 19:55:53 +0000 (15:55 -0400)]
api: stop defining __NR_x values for syscalls that don't exist
Historically libseccomp has created a __NR_x definition for every
syscall it supports, even those that aren't valid for a given ABI.
While this seemed like a good idea at the time, it turned out to have
some unwanted and nasty side effects. This patch finally corrects
this problem.
The basic approach is quite simple: move the SCMP_SYS() macro to use
__SNR_x values instead of __NR_x values. The unfortunate side effect
of this change is that instead of just worrying about #defines for the
__PNR_x values we now have to have a __SNR_x define for *every*
syscall. The good news is that after this patch that should only be
a few new syscalls every year - a very manageable task.
Reviewed-by: Tom Hromatka <tom.hromatka@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Jonah Petri [Thu, 12 Oct 2017 15:57:27 +0000 (11:57 -0400)]
python: fix error in pydoc
Fix the pydoc example so it's runnable.
Signed-off-by: Jonah Petri <jonah@petri.us> Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: fix subject line (add prefix)] Signed-off-by: Paul Moore <paul@paul-moore.com>
Felix Geyer [Mon, 15 Jul 2019 19:12:05 +0000 (21:12 +0200)]
python: install the python extension to the root package dir
Commit 8ad3638ea9023c3948976dfadebd1554380a31c9 effectively added libseccomp/
to the install path of the python extension.
This changed the import module name from "seccomp" to "libseccomp.seccomp",
breaking existing users.
Revert the install path like it was before 2.4.0
Signed-off-by: Felix Geyer <debfx@fobos.de>
[PM: tweaked the subject line] Signed-off-by: Paul Moore <paul@paul-moore.com>
Stephen Coleman [Sat, 22 Jun 2019 07:51:39 +0000 (15:51 +0800)]
arch: add support for io-uring related system calls in kernel 5.1
Signed-off-by: Stephen Coleman <omegacoleman@gmail.com> Reviewed-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: added the "arch:" subj prefix] Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Fri, 3 May 2019 02:06:54 +0000 (22:06 -0400)]
python: update the python bindings to support notifications
Here is the desciption from the main commit:
"Kernel 5.0 includes the new user notification return code. Here's
all the infrastructure to handle that.
The idea behind the user notification return code is that the
filter stops the syscall, and forwards it to a "listener fd" that
is created when installing a filter. Then then some userspace task
can listen and process events accordingly by taking some (or no)
action in userspace, and then returning a value from the command."
Paul Moore [Thu, 2 May 2019 23:29:59 +0000 (19:29 -0400)]
api: implement user notification in libseccomp
This patch is heavily based on an earlier patchset by Tycho
Andersen. I took Tycho's patch and incorporated the requested changes
from the review, fixed some corner case bugs, and simplified the API
a bit.
Kernel 5.0 includes the new user notification return code. Here's all the
infrastructure to handle that.
The idea behind the user notification return code is that the filter stops
the syscall, and forwards it to a "listener fd" that is created when
installing a filter. Then then some userspace task can listen and process
events accordingly by taking some (or no) action in userspace, and then
returning a value from the command.
Signed-off-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Wed, 1 May 2019 23:29:24 +0000 (19:29 -0400)]
python: use Cython language "3str"
Set the Cython language level to "3str" which is described in the
Cython 0.29 changelog:
"A new language level name 3str was added that mostly corresponds to
language level 3, but keeps unprefixed string literals as type ‘str’
in both Py2 and Py3, and the builtin ‘str’ type unchanged. This will
become the default in the next Cython release and is meant to help
user code a) transition more easily to this new default and
b) migrate to Python 3 source code semantics without making support
for Python 2.x difficult."
Paul Moore [Wed, 17 Apr 2019 20:36:57 +0000 (16:36 -0400)]
tests: only run test 50 on x86_64
Because of the way libseccomp handles non-native arch translations we
can't use arbitrary syscalls, e.g. 1000; we need to use syscalls that
are defined in the libseccomp syscall tables. Unfortunately, changing
the syscalls from 1000/1001 to a defined syscall appears to break the
test so let's just limit it to x86_64 for now.
Tom Hromatka [Wed, 10 Apr 2019 21:00:18 +0000 (15:00 -0600)]
tests: Add 50-sim-hash_collision test
libseccomp utilizes a hash table to manage BPF blocks. It
currently employs MurmurHash3 where the key is the hashed values
of the BPF instruction blocks, the accumulator start, and the
accumulator end. This test was added because of a mishandled
hash collision reported by Tor in GitHub issue #148.
* https://github.com/seccomp/libseccomp/issues/148
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tom Hromatka [Thu, 11 Apr 2019 18:43:06 +0000 (12:43 -0600)]
bpf: add accumulator state to the instruction block hash
This addresses a problem where dissimilar instruction blocks were
improperly hashed to the same value because we were not taking into
account the accumulator state.
See the GitHub issue below for more information:
* https://github.com/seccomp/libseccomp/issues/148
Reported-by: Toralf Förster <toralf.foerster@gmx.de> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Paul Moore [Thu, 7 Mar 2019 15:49:40 +0000 (10:49 -0500)]
bpf: pass the correct accumulator state to the next level
We were mistakenly passing the wrong accumulator state (the state at
the start of the instruction block, not at the end) which was causing
us to generate unnecessary load instructions.
Paul Moore [Thu, 7 Mar 2019 15:49:40 +0000 (10:49 -0500)]
db: fix 64-bit argument comparisons
Our approach to doing 64-bit comparisons using 32-bit operators was
just plain wrong, leading to a number of potential problems with
filters that used the LT, GT, LE, or GE operators. This patch fixes
this problem and a few other related issues that came to light in
the course of fixing the core problem.
A special thanks to Jann Horn for bringing this problem to our
attention.
Tycho Andersen [Wed, 6 Feb 2019 21:00:03 +0000 (14:00 -0700)]
system: add LOG action to seccomp.h
This return code was added in 4.14, so let's reflect that here.
Signed-off-by: Tycho Andersen <tycho@tycho.ws>
[PM: cleanup up some duplication with the existing SECCOMP_RET_LOG code] Signed-off-by: Paul Moore <paul@paul-moore.com>
Tycho Andersen [Wed, 6 Feb 2019 20:58:08 +0000 (13:58 -0700)]
system: update defines to match upstream
The kernel switched their defines to be more expressive like this, so let's
do the same. That will make it easy in future patches to copy and paste
definitions from the kernel :)
Signed-off-by: Tycho Andersen <tycho@tycho.ws> Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Tue, 15 Jan 2019 03:33:44 +0000 (22:33 -0500)]
api: provide 32-bit friendly argument comparison macros
We have a longstanding issue with 32-bit to 64-bit sign extension
inadvertently resulting in bogus syscall argument extensions. This
patch introduces a new set of argument comparison macros which
limit the argument values to 32-bit values so that we don't run into
problems with sign extension.
We use the macro overloading proposed by Roman at
https://kecher.net/overloading-macros/ to retain the feature of these
macros being usable as static initializers.
Thanks to @jdstrand on GitHub for reporting the problem.
Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Tom Hromatka [Fri, 8 Feb 2019 17:14:09 +0000 (10:14 -0700)]
arch: update the syscalls for Linux v5.0-rc5
Key changes include:
* Added __NR_statx, __NR_io_pgetevents, and __NR_rseq syscalls
to seccomp.h.in
* mips architecture now generates some of its syscall header
files. Added logic to arch-syscall-validate to create these
headers
* ppc architecture now uses a syscall.tbl
* s390 now uses a syscall.tbl
This addresses GitHub issue #136
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tom Hromatka [Tue, 5 Feb 2019 22:27:45 +0000 (15:27 -0700)]
db: Return -EDOM on endian mismatch during arch add
This commit clarifies the error code when seccomp_arch_add() or
seccomp_merge() fails due to an endian mismatch. Previously,
libseccomp would return -EEXIST if the new architecture's
endianness did not match.
This addresses GitHub Issue #86 - BUG: seccomp_arch_add() returns
-EEXISTS on endian mismatch
Reported-by: Michael Vogt <michael.vogt@gmail.com> Suggested-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tom Hromatka [Wed, 19 Sep 2018 15:26:25 +0000 (09:26 -0600)]
api: Add support for SCMP_ACT_KILL_PROCESS
This patch adds support for killing the entire process via
the SCMP_ACT_KILL_PROCESS action. To maintain backward
compatibility, SCMP_ACT_KILL defaults to SCMP_ACT_KILL_THREAD.
Support for KILL_PROCESS was added into the Linux kernel in
v4.14.
This addresses GitHub Issue #96 - RFE: add support for
SECCOMP_RET_KILL_PROCESS
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: minor comment tweak in seccomp.h.in] Signed-off-by: Paul Moore <paul@paul-moore.com>
Tom Hromatka [Tue, 15 May 2018 13:56:56 +0000 (07:56 -0600)]
pfc: fix PFC export hang on prioritized syscall with no rules (GH issue #117)
github user @varqox reported that generating PFC will hang if the
libseccomp filter contains a syscalle with a priority but no rule
set. The root cause is the while() loop in gen_pfc.c that walks
through the filter's syscalls. It wasn't properly advancing
through the list when p_iter was invalid.
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: fix a comment in the test] Signed-off-by: Paul Moore <paul@paul-moore.com>
Felix Abecassis [Fri, 1 Jun 2018 22:48:45 +0000 (15:48 -0700)]
python: fix operands in MASKED_EQ documentation
Fixes: https://github.com/seccomp/libseccomp/issues/119 Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
[PM: used full URL in the fixes line] Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Thu, 10 May 2018 23:25:34 +0000 (19:25 -0400)]
build: enable distcheck'ing for the python code
I'm not particularly proud of the seccomp.pyx hack, but it works, and
enabling the python bindings during the distcheck is definitely the
"Greater Good".
Paul Moore [Thu, 10 May 2018 20:59:49 +0000 (16:59 -0400)]
travis: move the code coverage testing to the "after_success" stage
For an as yet unknown reason we keep seeing build failures due to the
code coverage tests despite there not being any noticeable failures.
Move the gcov testing to "after_success" so that failures won't mark
the build as failing.
Tom Hromatka [Thu, 5 Apr 2018 21:39:21 +0000 (17:39 -0400)]
tests: add tests for db_chain_lt()
Add a test to improve the test coverage for db_chain_lt().
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: stripped the conversion from a macro to function, kept the test] Signed-off-by: Paul Moore <paul@paul-moore.com>
Tom Hromatka [Thu, 5 Apr 2018 18:57:23 +0000 (14:57 -0400)]
db: applied pcmoore's gist for GH issue #112
Note that as cited in the gist, this commit is not ready to be
committed yet. Specifically:
* investigate _db_tree_prune(), that likely needs some logic (lt/gt)
flipping to compensate for the changes in _db_tree_add()
* run the full regression test to ensure we aren't accidentally breaking
anything
* separate patch to add this test case to the regression tests
* separate patch to clear up the macros in src/db.h, see db_chain_lt() as
an example
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
[PM: subject line tweak, testing has proven this commit is OK and necessary
to restore proper db ordering, also fix the 'make check-syntax' errors] Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Wed, 17 Jan 2018 22:49:46 +0000 (17:49 -0500)]
all: massive src/db.c rework
First, and most importantly, let me state that this is perhaps the worst
possible example of a patch I can think of, and if anyone tries to submit
a PR/patch like this one I will reject it almost immediately. I'm only
merging this because 1) this patch escalated quickly, 2) splitting it would
require a disproportionate amount of time, and 3) this effort had blocked
other work for too long ... and, well, I'm the maintainer. Consider this
a bit of "maintainer privilege" if you will.
This patch started simply enough: the goal was to add/augment some tests to
help increase the libseccomp test coverage. Unfortunately, this particular
test improvement uncovered a rather tricky bug which escalated quite quickly
and soon involved a major rework of how we build the filter tree in src/db.c.
This rework brought about changes throughout the repository, including the
transaction and ABI specific code.
Tyler Hicks [Wed, 18 Oct 2017 06:16:57 +0000 (06:16 +0000)]
tests: add SCMP_ACT_LOG test to 06-sim-actions
Extend the 06-sim-actions set of tests to include tests for
SCMP_ACT_LOG. The CTL_KCHECKACTS global attribute must be set to prevent
test errors when running under an old kernel that doesn't support
SECCOMP_RET_LOG.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tyler Hicks [Wed, 18 Oct 2017 06:16:54 +0000 (06:16 +0000)]
system: runtime check if an action is supported by the kernel
As new actions are added to the kernel, libseccomp needs a way to
verify that an action is not only valid but also supported by the
current kernel at runtime. The only way to do this is by using the
SECCOMP_GET_ACTION_AVAIL operation which was added to seccomp(2) in
kernel version 4.14.
This check is not enabled for existing actions supported by libseccomp
since those actions were present in kernels at the inception of
libseccomp.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tyler Hicks [Wed, 18 Oct 2017 06:16:52 +0000 (06:16 +0000)]
all: add support for new log filter flag
Extend libseccomp to support SECCOMP_FILTER_FLAG_LOG, which is intended
to cause log events for all actions taken by a filter except for
SCMP_ACT_ALLOW actions. This is done via a new filter attribute called
SCMP_FLTATR_CTL_LOG that is off by default.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Tyler Hicks [Wed, 18 Oct 2017 06:16:47 +0000 (06:16 +0000)]
system: runtime check if a filter flag is supported by the kernel
As new filter flags are added to the kernel, libseccomp needs a way to
verify that a filter flag is not only valid but also supported by the
current kernel at runtime. A good way of doing that is by attempting to
enter filter mode, with the flag bit(s) in question set, and a NULL
pointer for the args parameter of seccomp(2). EFAULT indicates that the
flag is valid and EINVAL indicates that the flag is invalid. This patch
errs on the side of caution and treats any errno, besides EFAULT, as
indicating that the flag is invalid.
This check should be safe to use for the existing
SECCOMP_FILTER_FLAG_TSYNC flag so this patch enables the check for that
flag.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Thu, 21 Sep 2017 14:27:38 +0000 (10:27 -0400)]
api: create an API level construct as part of the supported API
This patch adds the concept of "API levels" which are a way of
indicating what functionality is supported at runtime. There are two
new API functions added, as explained by the manpage:
"The seccomp_api_get() function returns an integer representing the
functionality ("API level") provided by the current running kernel.
It is important to note that while seccomp_api_get() can be called
multiple times, the kernel is only probed the first time to see
what functionality is supported, all following calls to
seccomp_api_get() return a cached value.
The seccomp_api_set() function allows callers to force the API
level to the provided value; however, this is almost always a bad
idea and use of this function is strongly discouraged."