All of lore.kernel.org
 help / color / mirror / Atom feed
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.)

  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 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.