From: Tycho Andersen <tycho@tycho.ws>
To: Alban Crequy <alban.crequy@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Linux Containers <containers@lists.linux-foundation.org>,
Kees Cook <keescook@chromium.org>,
Andy Lutomirski <luto@amacapital.net>,
Oleg Nesterov <oleg@redhat.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
christian.brauner@ubuntu.com, tyhicks@canonical.com,
Akihiro Suda <suda.akihiro@lab.ntt.co.jp>,
me@tobin.cc
Subject: Re: [PATCH v3 4/4] seccomp: add support for passing fds via USER_NOTIF
Date: Sun, 3 Jun 2018 18:14:59 -0600 [thread overview]
Message-ID: <20180604001459.GD15998@cisco> (raw)
In-Reply-To: <CAMXgnP7cggXh0M403gqWALm0=Cq0JHJiDoE-q++BbL2hCZHX-g@mail.gmail.com>
Hi Alban,
On Sat, Jun 02, 2018 at 09:14:09PM +0200, Alban Crequy wrote:
> On Thu, 31 May 2018 at 16:52, Tycho Andersen <tycho@tycho.ws> wrote:
> >
> > The idea here is that the userspace handler should be able to pass an fd
> > back to the trapped task, for example so it can be returned from socket().
> >
> > I've proposed one API here, but I'm open to other options. In particular,
> > this only lets you return an fd from a syscall, which may not be enough in
> > all cases. For example, if an fd is written to an output parameter instead
> > of returned, the current API can't handle this. Another case is that
> > netlink takes as input fds sometimes (IFLA_NET_NS_FD, e.g.). If netlink
> > ever decides to install an fd and output it, we wouldn't be able to handle
> > this either.
> >
> > Still, the vast majority of interesting cases are covered by this API, so
> > perhaps it is Enough.
> >
> > I've left it as a separate commit for two reasons:
> > * It illustrates the way in which we would grow struct seccomp_notif and
> > struct seccomp_notif_resp without using netlink
> > * It shows just how little code is needed to accomplish this :)
> >
> > v2: new in v2
> > v3: no changes
> >
> > Signed-off-by: Tycho Andersen <tycho@tycho.ws>
> > CC: Kees Cook <keescook@chromium.org>
> > CC: Andy Lutomirski <luto@amacapital.net>
> > CC: Oleg Nesterov <oleg@redhat.com>
> > CC: Eric W. Biederman <ebiederm@xmission.com>
> > CC: "Serge E. Hallyn" <serge@hallyn.com>
> > CC: Christian Brauner <christian.brauner@ubuntu.com>
> > CC: Tyler Hicks <tyhicks@canonical.com>
> > CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
> > ---
> > include/uapi/linux/seccomp.h | 2 +
> > kernel/seccomp.c | 49 +++++++-
> > tools/testing/selftests/seccomp/seccomp_bpf.c | 112 ++++++++++++++++++
> > 3 files changed, 161 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> > index 8160e6cad528..3124427219cb 100644
> > --- a/include/uapi/linux/seccomp.h
> > +++ b/include/uapi/linux/seccomp.h
> > @@ -71,6 +71,8 @@ struct seccomp_notif_resp {
> > __u64 id;
> > __s32 error;
> > __s64 val;
> > + __u8 return_fd;
> > + __u32 fd;
> > };
> >
> > #endif /* _UAPI_LINUX_SECCOMP_H */
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 6dc99c65c2f4..2ee958b3efde 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -77,6 +77,8 @@ struct seccomp_knotif {
> > /* The return values, only valid when in SECCOMP_NOTIFY_REPLIED */
> > int error;
> > long val;
> > + struct file *file;
> > + unsigned int flags;
> >
> > /* Signals when this has entered SECCOMP_NOTIFY_REPLIED */
> > struct completion ready;
> > @@ -780,10 +782,32 @@ static void seccomp_do_user_notification(int this_syscall,
> > goto remove_list;
> > }
> >
> > - ret = n.val;
> > - err = n.error;
> > + if (n.file) {
> > + int fd;
> > +
> > + fd = get_unused_fd_flags(n.flags);
> > + if (fd < 0) {
> > + err = fd;
> > + ret = -1;
> > + goto remove_list;
> > + }
> > +
> > + ret = fd;
> > + err = 0;
> > +
> > + fd_install(fd, n.file);
> > + /* Don't fput, since fd has a reference now */
> > + n.file = NULL;
>
> Do we want the cgroup classid and netprio to be applied here, before
> the fd_install? I am looking at similar code in net/core/scm.c
> scm_detach_fds():
> sock = sock_from_file(fp[i], &err);
> if (sock) {
> sock_update_netprioidx(&sock->sk->sk_cgrp_data);
> sock_update_classid(&sock->sk->sk_cgrp_data);
> }
>
> The listener process might live in a different cgroup with a different
> classid & netprio, so it might not be applied as the app might expect.
Thanks, I hadn't really thought about this. I think doing what
SCM_RIGHTS does makes sense -- the operation is essentially the same.
> Also, should we update the struct sock_cgroup_data of the socket, in
> order to make the BPF helper function bpf_skb_under_cgroup() work wrt
> the cgroup of the target process instead of the listener process? I am
> looking at cgroup_sk_alloc(). I don't know what's the correct
> behaviour we want here.
SCM_RIGHTS seems to omit this (I assume you mean the val field of
struct sock_cgroup_data, which seems to be a pointer to struct
cgroup*), any idea why?
> > + } else {
> > + ret = n.val;
> > + err = n.error;
> > + }
> > +
> >
> > remove_list:
> > + if (n.file)
> > + fput(n.file);
> > +
> > list_del(&n.list);
> > out:
> > mutex_unlock(&match->notify_lock);
> > @@ -1598,6 +1622,27 @@ static ssize_t seccomp_notify_write(struct file *file, const char __user *buf,
> > knotif->state = SECCOMP_NOTIFY_REPLIED;
> > knotif->error = resp.error;
> > knotif->val = resp.val;
> > +
> > + if (resp.return_fd) {
> > + struct fd fd;
> > +
> > + /*
> > + * This is a little hokey: we need a real fget() (i.e. not
> > + * __fget_light(), which is what fdget does), but we also need
> > + * the flags from strcut fd. So, we get it, put it, and get it
> > + * again for real.
> > + */
> > + fd = fdget(resp.fd);
> > + knotif->flags = fd.flags;
> > + fdput(fd);
> > +
> > + knotif->file = fget(resp.fd);
> > + if (!knotif->file) {
> > + ret = -EBADF;
> > + goto out;
>
> Should the "knotif->state = SECCOMP_NOTIFY_REPLIED" and other changes
> be done after the error case here? In case of bad fd, it seems to
> return -EBADF the first time and -EINVAL the next time because the
> state would have been changed to SECCOMP_NOTIFY_REPLIED already.
Yes, good catch, thanks!
Tycho
next prev parent reply other threads:[~2018-06-04 0:15 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-31 14:49 [PATCH v3 0/4] seccomp trap to userspace Tycho Andersen
2018-05-31 14:49 ` [PATCH v3 1/4] seccomp: add a return code to " Tycho Andersen
2018-06-03 18:41 ` Jann Horn
2018-06-04 0:18 ` Tycho Andersen
2018-06-13 15:32 ` Jann Horn
2018-06-13 15:43 ` Jann Horn
[not found] ` <CA+RrjuW98m2coL+TOKq5cL0QhAb=HYxo2DpNoqMzdiwjqhc2BA@mail.gmail.com>
2018-06-12 23:16 ` Tycho Andersen
[not found] ` <CA+RrjuUtYoXfbH3cTbSY=QzXcxJsJOa0BL628ADy9N3bTO4=Mw@mail.gmail.com>
2018-06-14 21:03 ` Tycho Andersen
2018-06-14 21:53 ` Eric W. Biederman
2018-06-20 14:41 ` Tycho Andersen
2018-06-20 5:05 ` Tobin C . Harding
2018-06-20 5:53 ` Tobin C . Harding
[not found] ` <CA+RrjuUhFW+XU7RkZOM+f8cyDGOBjJrQHK3GruZmmCETb8ugfA@mail.gmail.com>
2018-06-20 14:55 ` Tycho Andersen
2018-05-31 14:49 ` [PATCH v3 2/4] seccomp: make get_nth_filter available outside of CHECKPOINT_RESTORE Tycho Andersen
2018-05-31 14:49 ` [PATCH v3 3/4] seccomp: add a way to get a listener fd from ptrace Tycho Andersen
2018-05-31 14:49 ` [PATCH v3 4/4] seccomp: add support for passing fds via USER_NOTIF Tycho Andersen
2018-06-02 13:13 ` Jann Horn
2018-06-02 18:18 ` Tycho Andersen
2018-06-02 19:14 ` Alban Crequy
2018-06-04 0:14 ` Tycho Andersen [this message]
2018-06-08 16:29 ` [PATCH v3 0/4] seccomp trap to userspace Kees Cook
2018-06-08 21:04 ` Tycho Andersen
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=20180604001459.GD15998@cisco \
--to=tycho@tycho.ws \
--cc=alban.crequy@gmail.com \
--cc=christian.brauner@ubuntu.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=me@tobin.cc \
--cc=oleg@redhat.com \
--cc=serge@hallyn.com \
--cc=suda.akihiro@lab.ntt.co.jp \
--cc=tyhicks@canonical.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 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 NNTP newsgroup(s).