From: Andy Lutomirski <luto@kernel.org>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>,
Andy Lutomirski <luto@kernel.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] seccomp
Date: Thu, 15 Aug 2019 12:21:13 -0700 [thread overview]
Message-ID: <CALCETrW=55Dd01Vpw5fJs3N0QFYWJzm1e0SUCKUCYNcHUUT9ow@mail.gmail.com> (raw)
In-Reply-To: <20190815183113.rtaevi3sdipdz5y2@wittgenstein>
On Thu, Aug 15, 2019 at 11:31 AM Christian Brauner
<christian.brauner@ubuntu.com> wrote:
>
> On Thu, Aug 15, 2019 at 11:26:10AM -0700, Andy Lutomirski wrote:
> > On Thu, Aug 15, 2019 at 10:48 AM Kees Cook <keescook@chromium.org> wrote:
> > >
> > > On Wed, Aug 14, 2019 at 10:54:49AM -0700, Andy Lutomirski wrote:
> > > > After thinking about this a bit more, I think that deferring the main
> > > > seccomp filter invocation until arguments have been read is too
> > > > problematic. It has the ordering issues you're thinking of, but it
> > > > also has unpleasant effects if one of the reads faults or if
> > > > SECCOMP_RET_TRACE or SECCOMP_RET_TRAP is used. I'm thinking that this
> > >
> > > Right, I was actually thinking of the trace/trap as being the race.
> > >
> > > > type of deeper inspection filter should just be a totally separate
> > > > layer. Once the main seccomp logic decides that a filterable syscall
> > > > will be issued then, assuming that no -EFAULT happens, a totally
> > > > different program should get run with access to arguments. And there
> > > > should be a way for the main program to know that the syscall nr in
> > > > question is filterable on the running kernel.
> > >
> > > Right -- this is how I designed the original prototype: it was
> > > effectively an LSM that was triggered by seccomp (since LSMs don't know
> > > anything about syscalls -- their hooks are more generalized). So seccomp
> > > would set a flag to make the LSM hook pay attention.
> > >
> > > Existing LSMs are system-owner defined, so really something like Landlock
> > > is needed for a process-owned LSM to be defined. But I worry that LSM
> > > hooks are still too "deep" in the kernel to have a process-oriented
> > > filter author who is not a kernel developer make any sense of the
> > > hooks. They're certainly oriented in a better position to gain the
> > > intent of a filter. For example, if a filter says "you can't open(2)
> > > /etc/foo", but it misses saying "you can't openat(2) /etc/foo", that's a
> > > dumb exposure. The LSM hooks are positioned to say "you can't manipulate
> > > /etc/foo through any means".
> > >
> > > So, I'm not entirely sure. It needs a clear design that chooses and
> > > justifies the appropriate "depth" of filtering. And FWIW, the two most
> > > frequent examples of argument parsing requests have been path-based
> > > checking and network address checking. So any prototype needs to handle
> > > these two cases sanely...
> > >
> >
> > But also clone() flag filtering, and new clone() proposals keep
> > wanting to add structs. And filtering bpf(). /me runs.
>
> Yeah, I've mentioned clone3() in my initial mail. And it is not a
> proposal anymore it's in mainline since the 5.3 merge window. So the
> evil has been done. /me (sorry-not-sorry) ducks :)
/me throws something squishy
So I guess we want some way for a seccomp filter to see clone3() being
called and determine that it or a related filter will be invoked again
with the arguments read before clone3() actually does anything. Doing
this with Landlock would involve poking quite a few places to add a
syscall, whereas my FILTERABLE thing would do it more simply.
These approaches aren't necessarily mutually exclusive. Maybe some
flags could be passed to the main seccomp filter so that it could
determine things like:
- This syscall is FILTERABLE and (optionally) these args will be filtered.
- Landlock will be called for filesystem access and the following
hooks are enabled.
The idea is that we want the ability to make additional syscalls be
FILTERABLE and/or to add new seccompable LSM hooks in new kernels.
Doing this in a way that has an acceptably low risk of accidentally
opening security holes when LSM hooks change will require quite a bit
of care.
next prev parent reply other threads:[~2019-08-15 19:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-19 9:35 [Ksummit-discuss] [TECH TOPIC] seccomp Christian Brauner
2019-07-19 12:32 ` Andy Lutomirski
2019-07-20 3:18 ` Kees Cook
2019-08-14 17:54 ` Andy Lutomirski
2019-08-15 17:48 ` Kees Cook
2019-08-15 18:26 ` Andy Lutomirski
2019-08-15 18:31 ` Christian Brauner
2019-08-15 19:21 ` Andy Lutomirski [this message]
2019-07-20 7:23 ` James Morris
2019-07-20 7:41 ` Christian Brauner
2019-07-25 14:18 ` Serge E. Hallyn
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='CALCETrW=55Dd01Vpw5fJs3N0QFYWJzm1e0SUCKUCYNcHUUT9ow@mail.gmail.com' \
--to=luto@kernel.org \
--cc=christian.brauner@ubuntu.com \
--cc=ksummit-discuss@lists.linuxfoundation.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 read-only IMAP folder(s) and NNTP newsgroup(s).