From: Christian Brauner <christian.brauner@ubuntu.com>
To: Tycho Andersen <tycho@tycho.ws>
Cc: Aleksa Sarai <asarai@suse.de>, Kees Cook <keescook@chromium.org>,
linux-api@vger.kernel.org, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] seccomp: Add group_leader pid to seccomp_notif
Date: Sun, 17 May 2020 16:35:41 +0200 [thread overview]
Message-ID: <20200517143541.lh2mzuvcg7anobpc@wittgenstein> (raw)
In-Reply-To: <20200517143311.fmxaf3pnopuaezl4@wittgenstein>
On Sun, May 17, 2020 at 04:33:11PM +0200, Christian Brauner wrote:
> On Sun, May 17, 2020 at 08:23:16AM -0600, Tycho Andersen wrote:
> > On Sun, May 17, 2020 at 09:21:56PM +1000, Aleksa Sarai wrote:
> > > On 2020-05-17, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> > > > Or... And that's more invasive but ultimately cleaner we v2 the whole
> > > > thing so e.g. SECCOMP_IOCTL_NOTIF_RECV2, SECCOMP_IOCTL_NOTIF_SEND2, and
> > > > embedd the size argument in the structs. Userspace sets the size
> > > > argument, we use get_user() to get the size first and then
> > > > copy_struct_from_user() to handle it cleanly based on that. A similar
> > > > model as with sched (has other unrelated quirks because they messed up
> > > > something too):
> > > >
> > > > static int sched_copy_attr(struct sched_attr __user *uattr, struct sched_attr *attr)
> > > > {
> > > > u32 size;
> > > > int ret;
> > > >
> > > > /* Zero the full structure, so that a short copy will be nice: */
> > > > memset(attr, 0, sizeof(*attr));
> > > >
> > > > ret = get_user(size, &uattr->size);
> > > > if (ret)
> > > > return ret;
> > > >
> > > > /* ABI compatibility quirk: */
> > > > if (!size)
> > > > size = SCHED_ATTR_SIZE_VER0;
> > > > if (size < SCHED_ATTR_SIZE_VER0 || size > PAGE_SIZE)
> > > > goto err_size;
> > > >
> > > > ret = copy_struct_from_user(attr, sizeof(*attr), uattr, size);
> > > > if (ret) {
> > > > if (ret == -E2BIG)
> > > > goto err_size;
> > > > return ret;
> > > > }
> > > >
> > > > We're probably the biggest user of this right now and I'd be ok with
> > > > that change. If it's a v2 than whatever. :)
> > >
> > > I'm :+1: on a new version and switch to copy_struct_from_user(). I was a
> > > little surprised when I found out that user_notif doesn't do it this
> > > way a while ago (and although in theory it is userspace's fault, ideally
> > > we could have an API that doesn't have built-in footguns).
> >
> > But I thought the whole point was that we couldn't do that, because
> > there's two things that can vary in length (struct seccomp_notif and
> > struct seccomp_data)?
>
> I may have missed that discussion you linked.
> But why wouldn't:
>
> struct seccomp_notif2 {
> __u32 notif_size;
> __u64 id;
> __u32 pid;
> __u32 flags;
> struct seccomp_data data;
> __u32 data_size;
> };
>
> struct seccomp_notif_resp2 {
> __u32 notif_resp_size;
> __u64 id;
> __s64 val;
> __s32 error;
> __u32 flags;
> };
(Ignore the missing 32 bits here.)
next prev parent reply other threads:[~2020-05-17 14:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 23:40 [PATCH] seccomp: Add group_leader pid to seccomp_notif Sargun Dhillon
2020-05-17 7:17 ` Kees Cook
2020-05-17 10:47 ` Christian Brauner
2020-05-17 11:21 ` Aleksa Sarai
2020-05-17 14:23 ` Tycho Andersen
2020-05-17 14:33 ` Christian Brauner
2020-05-17 14:35 ` Christian Brauner [this message]
2020-05-17 14:46 ` Tycho Andersen
2020-05-17 15:02 ` Tycho Andersen
2020-05-17 21:30 ` Kees Cook
2020-05-18 8:32 ` Sargun Dhillon
2020-05-18 12:45 ` Christian Brauner
2020-05-18 13:23 ` Tycho Andersen
2020-05-18 14:00 ` Christian Brauner
2020-05-18 12:05 ` Christian Brauner
2020-05-18 21:10 ` Kees Cook
2020-05-18 12:53 ` Christian Brauner
2020-05-18 13:20 ` Tycho Andersen
2020-05-18 21:37 ` Sargun Dhillon
2020-05-17 11:17 ` Sargun Dhillon
2020-05-18 23:08 ` Eric W. Biederman
2020-05-22 17:54 ` Sargun Dhillon
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=20200517143541.lh2mzuvcg7anobpc@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=asarai@suse.de \
--cc=containers@lists.linux-foundation.org \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tycho@tycho.ws \
/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