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."
Tyler Hicks [Thu, 24 Aug 2017 19:28:13 +0000 (19:28 +0000)]
tests: fix conditional that was skipping all basic python tests
A conditional added in ec6f45ab was incorrectly comparing the (empty)
stdout of grep -q against 0, which always evaluated to be true and
skipped the basic python tests.
Fix it by using bash's pattern matching.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
Paul Moore [Thu, 23 Feb 2017 20:24:58 +0000 (15:24 -0500)]
all: convert our hash from Lookup3 to MurmurHash3
The hash implementation was taken from the GitHub project below
where it was released into the public domain. MurmurHash3 should be
faster and less complex than the Lookup3 hash it replaces.
Paul Moore [Wed, 15 Feb 2017 20:33:39 +0000 (15:33 -0500)]
bpf: don't catch the -1 syscall in the x32/x86_64 check
The -1 syscall can be used by a tracing process to skip a syscall,
which up until Linux v4.8 was of no concern for libseccomp since the
seccomp filter was only executed at the start of the syscall and not
after the tracing process was notified, however recent kernels also
execute the seccomp filter after the tracing process finishes its
syscall handling; this caused problems on x86_64 systems that didn't
explicitly add an x32 architecture to their filters.
This patch fixes the x32 check to treat the -1 syscall like any other
syscall.
Paul Moore [Thu, 16 Feb 2017 00:10:35 +0000 (19:10 -0500)]
all: treat syscall -1 as a valid syscall
Process tracers use a -1 syscall value to indicate that a syscall
should be skipped. This turns out to be quite an undertaking as
we need to workaround __NR_SCMP_ERROR (which also has a value of
-1). Pay special attention to the new attribute,
SCMP_FLTATR_API_TSKIP, and the documentation additions.
More information in the GitHub issue:
* https://github.com/seccomp/libseccomp/issues/80
Luca Bruno [Mon, 11 Jul 2016 13:06:52 +0000 (15:06 +0200)]
man: clarify syscall number rewriting
In case of multiplexed syscalls, syscall name resolver and rule builder
both offer additional functions to ignore or perform syscall number
rewriting.
This commit introduces additional explicit details to the corresponding
manpages.
Signed-off-by: Luca Bruno <lucab@debian.org>
[PM: minor man-page style fixes] Signed-off-by: Paul Moore <paul@paul-moore.com>