lkml.org 
[lkml]   [2017]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 0/2] Begin auditing SECCOMP_RET_ERRNO return actions
    On Mon, Jan 2, 2017 at 2:47 PM, Paul Moore <paul@paul-moore.com> wrote:
    > On Mon, Jan 2, 2017 at 11:53 AM, Tyler Hicks <tyhicks@canonical.com> wrote:
    >> This patch set creates the basis for auditing information specific to a given
    >> seccomp return action and then starts auditing SECCOMP_RET_ERRNO return
    >> actions. The audit messages for SECCOMP_RET_ERRNO return actions include the
    >> errno value that will be returned to userspace.
    >
    > I'm replying to this patchset posting because it his my inbox first,
    > but my comments here apply to both this patchset and the other
    > seccomp/audit patchset you posted.
    >
    > In my experience, we have two or three problems (the count varies
    > depending on perspective) when it comes to seccomp filter reporting:
    >
    > 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.
    >
    > My current thinking - forgive me, this has been kicking around in my
    > head for the better part of six months (longer?) and I haven't
    > attempted to code it up - is to create a sysctl knob for a system wide
    > seccomp logging threshold that would be applied to the high 16-bits of
    > *every* triggered action: if the action was at/below the threshold a
    > record would be emitted, otherwise silence. This should resolve
    > problems #1 and #2, and the code should be relatively straightforward
    > and small.
    >
    > As part of the code above, I expect that all seccomp logging would get
    > routed through a single logging function (sort of like a better
    > implementation of the existing audit_seccomp()) that would check the
    > threshold and trigger the logging if needed. This function could be
    > augmented to check for CONFIG_AUDIT and in the case where audit was
    > not built into the kernel, a simple printk could be used to log the
    > seccomp event; solving problem #3.

    Would this not be doable with a seccomp tracepoint and a BPF filter?

    --Andy

    \
     
     \ /
      Last update: 2017-01-03 06:57    [W:4.117 / U:0.112 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site