[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1486100262-32391-1-git-send-email-tyhicks@canonical.com>
Date: Fri, 3 Feb 2017 05:37:38 +0000
From: Tyler Hicks <tyhicks@...onical.com>
To: Paul Moore <paul@...l-moore.com>, Eric Paris <eparis@...hat.com>,
Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...capital.net>,
Will Drewry <wad@...omium.org>
Cc: linux-audit@...hat.com, linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/4] Improved seccomp logging
This patch set is the second revision of the following two previously
submitted patch sets:
http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhicks@canonical.com
http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhicks@canonical.com
The patch set aims to address some known deficiencies in seccomp's current
logging capabilities:
1. Inability to log all filter actions.
2. Inability to selectively enable filtering; e.g. devs want noisy logging,
users want relative quiet.
3. Consistent behavior with audit enabled and disabled.
4. Inability to easily develop a filter due to the lack of a
permissive/complain mode.
The first three items were outlined by Paul Moore and are issues that I agree
with. The last one is one that I'm particularly interested in.
I deviated a little from the plan that he laid out to address the third issue.
Looking back at Paul's feedback, he wanted a way to log seccomp actions even
when the audit subsystem is disabled at build time. I felt like the bigger
problem is that, while it is common for kernels to be built with audit support,
it is far less common to actually have auditd running. Therefore, my approach
was to improve the situation when kernel audit support is enabled at build time
but audit_enabled is false at runtime. The audit subsystem forwards messages
onto syslog in that situation.
Tyler
Powered by blists - more mailing lists