From: Kees Cook <keescook@chromium.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Tyler Hicks <tyhicks@canonical.com>,
Paul Moore <paul@paul-moore.com>, Eric Paris <eparis@redhat.com>,
Will Drewry <wad@chromium.org>,
linux-audit@redhat.com,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
John Crispin <john@phrozen.org>,
linux-api@ver.kernel.org
Subject: Re: [PATCH v3 0/4] Improved seccomp logging
Date: Thu, 16 Feb 2017 15:29:19 -0800 [thread overview]
Message-ID: <CAGXu5j+muyh2bwtMXDHuUHsDV9ZyEY-hMHrJjVuX2vC20MVSZw@mail.gmail.com> (raw)
In-Reply-To: <CALCETrXbPQg2V_=3OqZRXbzOf7zGJ8V_RZ5YQ5CHtEEkA0n5HQ@mail.gmail.com>
On Wed, Feb 15, 2017 at 7:24 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Mon, Feb 13, 2017 at 7:45 PM, Tyler Hicks <tyhicks@canonical.com> wrote:
>> This patch set is the third revision of the following two previously
>> submitted patch sets:
>>
>> v1: http://lkml.kernel.org/r/1483375990-14948-1-git-send-email-tyhicks@canonical.com
>> v1: http://lkml.kernel.org/r/1483377999-15019-2-git-send-email-tyhicks@canonical.com
>>
>> v2: http://lkml.kernel.org/r/1486100262-32391-1-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.
>
> I think I dislike this, but I think my dislikes may be fixable with
> minor changes.
>
> What I dislike is that this mixes app-specific built-in configuration
> (seccomp) with global privileged stuff (audit). The result is a
> potentially difficult to use situation in which you need to modify an
> app to make it loggable (using RET_LOG) and then fiddle with
> privileged config (auditctl, etc) to actually see the logs.
You make a good point about RET_LOG vs log_max_action. I think making
RET_LOG the default value would work for 99% of the cases.
> What if, instead of logging straight to the audit log, SECCOMP_RET_LOG
> [1] merely meant "tell our parent about this syscall"? (Ideally we'd
> also figure out a way to express "log this and allow", "log this and
> do ERRNO", etc.) Then we could have another mechanism that installs a
> layer in the seccomp stack that, instead of catching syscalls, catches
> log events and sticks them in a ring buffer (or audit).
So, I really don't like this because it's yet another logging system.
We already have a security event logger: audit. This continues to use
that subsystem without changing semantics very much.
> Concretely, it might work like this. If a filter returns
> SECCOMP_RET_LOG, then we "log" and keep processing. SECCOMP_RET_LOG
> is otherwise treated literally like SECCOMP_RET_ALLOW and has no
> effect on return value. If you want log-and-kill, you install two
> filters.
>
> There's a new seccomp(2) action that returns an fd. That fd
> references a new thing in the seccomp stack that is a BPF program that
> is called whenever SECCOMP_RET_LOG is returned from lower down. The
> output of this filter determines whether the log event is ignored,
> stuck in the ring buffer, or passed up the stack for further
> processing. You read(2) the fd to access the ring buffer.
>
> Using this mechanism, you could write a simple seccomptrace tool that
> needs no privilege and dumps SECCOMP_RET_LOG events from the target
> program to stderr.
If someone was going to do this, they could just as well set up a
tracer to use RET_TRAP. (And this is what things like minijail does
already, IIRC.) The reality of the situation is that this is way too
much overhead for the common case. We need a generalized logging
system that uses the existing logging mechanisms.
> Thoughts?
>
> [1] If we went this route, it might want to be renamed.
>
> P.S. We ought to be able to write a BPF verifier pass that makes sure
> that filters don't return unsupported return values if we cared to do
> so.
Can we? I thought the BPF_RET used the BPF registers, and validating
that might be less-than-easy?
-Kees
--
Kees Cook
Pixel Security
next prev parent reply other threads:[~2017-02-16 23:29 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 3:45 [PATCH v3 0/4] Improved seccomp logging Tyler Hicks
2017-02-14 3:45 ` [PATCH v3 1/4] seccomp: Add sysctl to display available actions Tyler Hicks
2017-02-16 1:00 ` Kees Cook
2017-02-16 3:14 ` Andy Lutomirski
2017-02-14 3:45 ` [PATCH v3 2/4] seccomp: Add sysctl to configure actions that should be logged Tyler Hicks
2017-02-14 3:45 ` [PATCH v3 3/4] seccomp: Create an action to log before allowing Tyler Hicks
2017-02-14 3:45 ` [PATCH v3 4/4] seccomp: Add tests for SECCOMP_RET_LOG Tyler Hicks
2017-02-16 3:24 ` [PATCH v3 0/4] Improved seccomp logging Andy Lutomirski
2017-02-16 23:29 ` Kees Cook [this message]
2017-02-17 17:00 ` Andy Lutomirski
2017-02-22 18:39 ` Kees Cook
[not found] ` <CAGXu5j+muyh2bwtMXDHuUHsDV9ZyEY-hMHrJjVuX2vC20MVSZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-02-22 18:46 ` Kees Cook
[not found] ` <CAGXu5jLtLgYmDJDfGA2EtfB7Fqze-SP768ezq=fgWZ=X-ObW3w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-07 22:16 ` Tyler Hicks
[not found] ` <ac79529e-f6b6-690c-e597-5adeb75b0f25-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2017-04-07 22:46 ` Kees Cook
[not found] ` <CAGXu5j+qUOpnDeF4TMH2AXXgHZB_WfHHfxe3TBSShmneisR-Lg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-07 23:46 ` Tyler Hicks
2017-04-11 3:59 ` Kees Cook
2017-04-27 22:17 ` Tyler Hicks
[not found] ` <0b1a2337-7006-e7cb-f519-dec389ede041-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2017-04-27 23:42 ` Kees Cook
2017-05-02 2:41 ` Tyler Hicks
2017-05-02 16:14 ` Andy Lutomirski
2017-04-10 15:18 ` Steve Grubb
2017-04-10 15:57 ` Andy Lutomirski
[not found] ` <CALCETrXJKtnXmzRHs=7mEXN7FVAYjzxKb=jwrqwXQoXB0dHHPg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-04-10 19:22 ` Tyler Hicks
2017-04-11 4:03 ` Kees Cook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGXu5j+muyh2bwtMXDHuUHsDV9ZyEY-hMHrJjVuX2vC20MVSZw@mail.gmail.com \
--to=keescook@chromium.org \
--cc=eparis@redhat.com \
--cc=john@phrozen.org \
--cc=linux-api@ver.kernel.org \
--cc=linux-audit@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=paul@paul-moore.com \
--cc=tyhicks@canonical.com \
--cc=wad@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).