summaryrefslogtreecommitdiff
path: root/Documentation/userspace-api
diff options
context:
space:
mode:
authorTyler Hicks <tyhicks@canonical.com>2018-05-04 01:08:15 +0000
committerPaul Moore <paul@paul-moore.com>2018-05-08 02:04:23 -0400
commit326bee0286d7f6b0d780f5b75a35ea9fe489a802 (patch)
treef1eb4381cc90194fe772decba3168e578981993e /Documentation/userspace-api
parentea6eca778500b0aaf6e5f10dac4d2cd745c2a50b (diff)
seccomp: Don't special case audited processes when logging
Seccomp logging for "handled" actions such as RET_TRAP, RET_TRACE, or RET_ERRNO can be very noisy for processes that are being audited. This patch modifies the seccomp logging behavior to treat processes that are being inspected via the audit subsystem the same as processes that aren't under inspection. Handled actions will no longer be logged just because the process is being inspected. Since v4.14, applications have the ability to request logging of handled actions by using the SECCOMP_FILTER_FLAG_LOG flag when loading seccomp filters. With this patch, the logic for deciding if an action will be logged is: if action == RET_ALLOW: do not log else if action not in actions_logged: do not log else if action == RET_KILL: log else if action == RET_LOG: log else if filter-requests-logging: log else: do not log Reported-by: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Paul Moore <paul@paul-moore.com>
Diffstat (limited to 'Documentation/userspace-api')
-rw-r--r--Documentation/userspace-api/seccomp_filter.rst7
1 files changed, 0 insertions, 7 deletions
diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst
index 099c412951d6..82a468bc7560 100644
--- a/Documentation/userspace-api/seccomp_filter.rst
+++ b/Documentation/userspace-api/seccomp_filter.rst
@@ -207,13 +207,6 @@ directory. Here's a description of each file in that directory:
to the file do not need to be in ordered form but reads from the file
will be ordered in the same way as the actions_avail sysctl.
- It is important to note that the value of ``actions_logged`` does not
- prevent certain actions from being logged when the audit subsystem is
- configured to audit a task. If the action is not found in
- ``actions_logged`` list, the final decision on whether to audit the
- action for that task is ultimately left up to the audit subsystem to
- decide for all seccomp return values other than ``SECCOMP_RET_ALLOW``.
-
The ``allow`` string is not accepted in the ``actions_logged`` sysctl
as it is not possible to log ``SECCOMP_RET_ALLOW`` actions. Attempting
to write ``allow`` to the sysctl will result in an EINVAL being