From: Kees Cook <keescook@chromium.org>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: luto@amacapital.net, jannh@google.com, wad@chromium.org,
shuah@kernel.org, ast@kernel.org, daniel@iogearbox.net,
kafai@fb.com, songliubraving@fb.com, yhs@fb.com,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
netdev@vger.kernel.org, bpf@vger.kernel.org,
Tycho Andersen <tycho@tycho.ws>,
Tyler Hicks <tyhicks@canonical.com>
Subject: Re: [PATCH v2 1/3] seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
Date: Thu, 10 Oct 2019 14:45:38 -0700 [thread overview]
Message-ID: <201910101440.17A13952@keescook> (raw)
In-Reply-To: <20190920083007.11475-2-christian.brauner@ubuntu.com>
On Fri, Sep 20, 2019 at 10:30:05AM +0200, Christian Brauner wrote:
> + * Similar precautions should be applied when stacking SECCOMP_RET_USER_NOTIF.
> + * For SECCOMP_RET_USER_NOTIF filters acting on the same syscall the uppermost
> + * filter takes precedence. This means that the uppermost
> + * SECCOMP_RET_USER_NOTIF filter can override any SECCOMP_IOCTL_NOTIF_SEND from
> + * lower filters essentially allowing all syscalls to pass by using
> + * SECCOMP_USER_NOTIF_FLAG_CONTINUE. Note that SECCOMP_RET_USER_NOTIF can
^^^^^^^^^^^^^^
This is meant to read RET_TRACE, yes?
> + * equally be overriden by SECCOMP_USER_NOTIF_FLAG_CONTINUE.
I rewrote this paragraph with that corrected and swapping some
"upper/lower" to "most recently added" etc:
+ * Similar precautions should be applied when stacking SECCOMP_RET_USER_NOTIF
+ * or SECCOMP_RET_TRACE. For SECCOMP_RET_USER_NOTIF filters acting on the
+ * same syscall, the most recently added filter takes precedence. This means
+ * that the new SECCOMP_RET_USER_NOTIF filter can override any
+ * SECCOMP_IOCTL_NOTIF_SEND from earlier filters, essentially allowing all
+ * such filtered syscalls to be executed by sending the response
+ * SECCOMP_USER_NOTIF_FLAG_CONTINUE. Note that SECCOMP_RET_TRACE can equally
+ * be overriden by SECCOMP_USER_NOTIF_FLAG_CONTINUE.
Ultimately, I think this caveat is fine. RET_USER_NOTIF and RET_TRACE are
both used from the "process manager" use-case. The benefits of "continue"
semantics here outweighs the RET_USER_NOTIF and RET_TRACE "bypass". If
we end up in a situation where we need to deal with some kind of
nesting where this is a problem in practice, we can revisit this.
Applied to my for-next/seccomp. Thanks!
--
Kees Cook
next prev parent reply other threads:[~2019-10-10 21:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 8:30 [PATCH v2 0/3] seccomp: continue syscall from notifier Christian Brauner
2019-09-20 8:30 ` [PATCH v2 1/3] seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE Christian Brauner
2019-10-10 21:45 ` Kees Cook [this message]
2019-10-11 9:46 ` Christian Brauner
2019-09-20 8:30 ` [PATCH v2 2/3] seccomp: avoid overflow in implicit constant conversion Christian Brauner
2019-09-20 8:47 ` Tycho Andersen
2019-09-20 8:30 ` [PATCH v2 3/3] seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE Christian Brauner
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=201910101440.17A13952@keescook \
--to=keescook@chromium.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christian.brauner@ubuntu.com \
--cc=daniel@iogearbox.net \
--cc=jannh@google.com \
--cc=kafai@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=netdev@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=songliubraving@fb.com \
--cc=tycho@tycho.ws \
--cc=tyhicks@canonical.com \
--cc=wad@chromium.org \
--cc=yhs@fb.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.