All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aleksa Sarai <cyphar@cyphar.com>
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: Sargun Dhillon <sargun@sargun.me>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	tycho@tycho.ws, jannh@google.com, keescook@chromium.org
Subject: Re: [PATCH] seccomp: Check flags on seccomp_notif is unset
Date: Fri, 27 Dec 2019 13:24:46 +1100	[thread overview]
Message-ID: <20191227022446.37e64ag4uaqms2w4@yavin.dot.cyphar.com> (raw)
In-Reply-To: <57C06925-0CC6-4251-AD57-8FF1BC28F049@ubuntu.com>

[-- Attachment #1: Type: text/plain, Size: 3564 bytes --]

On 2019-12-26, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> On December 26, 2019 3:32:29 PM GMT+01:00, Aleksa Sarai <cyphar@cyphar.com> wrote:
> >On 2019-12-26, Christian Brauner <christian.brauner@ubuntu.com> wrote:
> >> On Wed, Dec 25, 2019 at 09:45:33PM +0000, Sargun Dhillon wrote:
> >> > This patch is a small change in enforcement of the uapi for
> >> > SECCOMP_IOCTL_NOTIF_RECV ioctl. Specificaly, the datastructure
> >which is
> >> > passed (seccomp_notif), has a flags member. Previously that could
> >be
> >> > set to a nonsense value, and we would ignore it. This ensures that
> >> > no flags are set.
> >> > 
> >> > Signed-off-by: Sargun Dhillon <sargun@sargun.me>
> >> > Cc: Kees Cook <keescook@chromium.org>
> >> 
> >> I'm fine with this since we soon want to make use of the flag
> >argument
> >> when we add a flag to get a pidfd from the seccomp notifier on
> >receive.
> >> The major users I could identify already pass in seccomp_notif with
> >all
> >> fields set to 0. If we really break users we can always revert; this
> >> seems very unlikely to me though.
> >> 
> >> One more question below, otherwise:
> >> 
> >> Reviewed-by: Christian Brauner <christian.brauner@ubuntu.com>
> >> 
> >> > ---
> >> >  kernel/seccomp.c | 7 +++++++
> >> >  1 file changed, 7 insertions(+)
> >> > 
> >> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> >> > index 12d2227e5786..455925557490 100644
> >> > --- a/kernel/seccomp.c
> >> > +++ b/kernel/seccomp.c
> >> > @@ -1026,6 +1026,13 @@ static long seccomp_notify_recv(struct
> >seccomp_filter *filter,
> >> >  	struct seccomp_notif unotif;
> >> >  	ssize_t ret;
> >> >  
> >> > +	if (copy_from_user(&unotif, buf, sizeof(unotif)))
> >> > +		return -EFAULT;
> >> > +
> >> > +	/* flags is reserved right now, make sure it's unset */
> >> > +	if (unotif.flags)
> >> > +		return -EINVAL;
> >> > +
> >> 
> >> Might it make sense to use
> >> 
> >> 	err = copy_struct_from_user(&unotif, sizeof(unotif), buf,
> >sizeof(unotif));
> >> 	if (err)
> >> 		return err;
> >> 
> >> This way we check that the whole struct is 0 and report an error as
> >soon
> >> as one of the members is non-zero. That's more drastic but it'd
> >ensure
> >> that other fields can be used in the future for whatever purposes.
> >> It would also let us get rid of the memset() below. 
> >
> >Given that this isn't an extensible struct, it would be simpler to just
> >do
> >check_zeroed_user() -- copy_struct_from_user() is overkill. That would
> >also remove the need for any copy_from_user()s and the memset can be
> >dropped by just doing
> >
> >  struct seccomp_notif unotif = {};
> >
> >> >  	memset(&unotif, 0, sizeof(unotif));
> >> >  
> >> >  	ret = down_interruptible(&filter->notif->request);
> >> > -- 
> >> > 2.20.1
> >> > 
> 
> It is an extensible struct. That's why we have notifier size checking built in.

Ah right, NOTIF_GET_SIZES. I reckon check_zeroed_user() is still a bit
simpler since none of the fields are used right now (and really, this
patch should be checking all of them, not just ->flags, if we want to
use any of them in the future).

But sure, copy_struct_from_user() also makes sense since it is
extensible (though I personally do find the whole NOTIF_GET_SIZES thing
a bit scary -- but that's water under the bridge at this point, and as
long as userspace is clever enough it shouldn't be a problem).

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2019-12-27  2:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-25 21:45 [PATCH] seccomp: Check flags on seccomp_notif is unset Sargun Dhillon
2019-12-26 11:52 ` Christian Brauner
2019-12-26 14:32   ` Aleksa Sarai
2019-12-26 14:34     ` Christian Brauner
2019-12-27  2:24       ` Aleksa Sarai [this message]
2019-12-27  2:31         ` Aleksa Sarai
2019-12-27 11:47           ` Christian Brauner
2019-12-27 14:22             ` Sargun Dhillon
2019-12-27 14:38               ` Tycho Andersen
2019-12-27 15:15               ` Aleksa Sarai
2019-12-27 15:32                 ` Christian Brauner
2019-12-26 15:37     ` Tycho Andersen
2019-12-27  2:28       ` Aleksa Sarai

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=20191227022446.37e64ag4uaqms2w4@yavin.dot.cyphar.com \
    --to=cyphar@cyphar.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sargun@sargun.me \
    --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.