[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1524856562-22566-1-git-send-email-tyhicks@canonical.com>
Date: Fri, 27 Apr 2018 19:15:59 +0000
From: Tyler Hicks <tyhicks@...onical.com>
To: linux-kernel@...r.kernel.org
Cc: Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>,
Paul Moore <paul@...l-moore.com>,
Eric Paris <eparis@...hat.com>,
Steve Grubb <sgrubb@...hat.com>,
Jonathan Corbet <corbet@....net>, linux-audit@...hat.com,
linux-security-module@...r.kernel.org, linux-doc@...r.kernel.org
Subject: [PATCH 0/3] Better integrate seccomp logging and auditing
Seccomp received improved logging controls in v4.14. Applications can opt into
logging of "handled" actions (SECCOMP_RET_TRAP, SECCOMP_RET_TRACE,
SECCOMP_RET_ERRNO) using the SECCOMP_FILTER_FLAG_LOG bit when loading filters.
They can also debug filter matching with the new SECCOMP_RET_LOG action.
Administrators can prevent specific actions from being logged using the
kernel.seccomp.actions_logged sysctl.
However, one corner case intentionally wasn't addressed in those v4.14 changes.
When a process is being inspected by the audit subsystem, seccomp's decision
making for logging ignores the new controls and unconditionally logs every
action taken except for SECCOMP_RET_ALLOW. This isn't particularly useful since
many existing applications don't intend to log handled actions due to them
occurring very frequently. This amount of logging fills the audit logs without
providing many benefits now that application authors have fine grained controls
at their disposal.
This patch set aligns the seccomp logging behavior for both audited and
unaudited processes. It also emits an audit record, if auditing is enabled,
when the kernel.seccomp.actions_logged sysctl is written to so that there's a
paper trail when entire actions are quieted.
Tyler
Powered by blists - more mailing lists