From: Christian Brauner <christian.brauner@ubuntu.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: "Kees Cook" <keescook@chromium.org>,
LKML <linux-kernel@vger.kernel.org>,
containers@lists.linux.dev, "Tycho Andersen" <tycho@tycho.pizza>,
"Andy Lutomirski" <luto@kernel.org>,
"Rodrigo Campos" <rodrigo@kinvolk.io>,
"Mauricio Vásquez Bernal" <mauricio@kinvolk.io>,
"Giuseppe Scrivano" <gscrivan@redhat.com>,
"Mickaël Salaün" <mic@linux.microsoft.com>
Subject: Re: [PATCH v2 3/4] seccomp: Support atomic "addfd + send reply"
Date: Fri, 21 May 2021 17:45:32 +0200 [thread overview]
Message-ID: <20210521154532.utttvofngdg6qeob@wittgenstein> (raw)
In-Reply-To: <20210517193908.3113-4-sargun@sargun.me>
On Mon, May 17, 2021 at 12:39:07PM -0700, Sargun Dhillon wrote:
> From: Rodrigo Campos <rodrigo@kinvolk.io>
>
> Alban Crequy reported a race condition userspace faces when we want to
> add some fds and make the syscall return them[1] using seccomp notify.
>
> The problem is that currently two different ioctl() calls are needed by
> the process handling the syscalls (agent) for another userspace process
> (target): SECCOMP_IOCTL_NOTIF_ADDFD to allocate the fd and
> SECCOMP_IOCTL_NOTIF_SEND to return that value. Therefore, it is possible
> for the agent to do the first ioctl to add a file descriptor but the
> target is interrupted (EINTR) before the agent does the second ioctl()
> call.
>
> This patch adds a flag to the ADDFD ioctl() so it adds the fd and
> returns that value atomically to the target program, as suggested by
> Kees Cook[2]. This is done by simply allowing
> seccomp_do_user_notification() to add the fd and return it in this case.
> Therefore, in this case the target wakes up from the wait in
> seccomp_do_user_notification() either to interrupt the syscall or to add
> the fd and return it.
>
> This "allocate an fd and return" functionality is useful for syscalls
> that return a file descriptor only, like connect(2). Other syscalls that
> return a file descriptor but not as return value (or return more than
> one fd), like socketpair(), pipe(), recvmsg with SCM_RIGHTs, will not
> work with this flag.
>
> This effectively combines SECCOMP_IOCTL_NOTIF_ADDFD and
> SECCOMP_IOCTL_NOTIF_SEND into an atomic opteration. The notification's
> return value, nor error can be set by the user. Upon successful invocation
> of the SECCOMP_IOCTL_NOTIF_ADDFD ioctl with the SECCOMP_ADDFD_FLAG_SEND
> flag, the notifying process's errno will be 0, and the return value will
> be the file descriptor number that was installed.
>
> [1]: https://lore.kernel.org/lkml/CADZs7q4sw71iNHmV8EOOXhUKJMORPzF7thraxZYddTZsxta-KQ@mail.gmail.com/
> [2]: https://lore.kernel.org/lkml/202012011322.26DCBC64F2@keescook/
>
> Signed-off-by: Rodrigo Campos <rodrigo@kinvolk.io>
> Signed-off-by: Sargun Dhillon <sargun@sargun.me>
> Acked-by: Tycho Andersen <tycho@tycho.pizza>
> ---
> .../userspace-api/seccomp_filter.rst | 12 +++++
> include/uapi/linux/seccomp.h | 1 +
> kernel/seccomp.c | 49 +++++++++++++++++--
> 3 files changed, 58 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/userspace-api/seccomp_filter.rst b/Documentation/userspace-api/seccomp_filter.rst
> index 6efb41cc8072..d61219889e49 100644
> --- a/Documentation/userspace-api/seccomp_filter.rst
> +++ b/Documentation/userspace-api/seccomp_filter.rst
> @@ -259,6 +259,18 @@ and ``ioctl(SECCOMP_IOCTL_NOTIF_SEND)`` a response, indicating what should be
> returned to userspace. The ``id`` member of ``struct seccomp_notif_resp`` should
> be the same ``id`` as in ``struct seccomp_notif``.
>
> +Userspace can also add file descriptors to the notifying process via
> +``ioctl(SECCOMP_IOCTL_NOTIF_ADDFD)``. The ``id`` member of
> +``struct seccomp_notif_addfd`` should be the same ``id`` as in
> +``struct seccomp_notif``. The ``newfd_flags`` flag may be used to set flags
> +like O_EXEC on the file descriptor in the notifying process. If the supervisor
nit:
s/O_EXEC/O_CLOEXEC/
next prev parent reply other threads:[~2021-05-21 15:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-17 19:39 [PATCH v2 0/4] Atomic addfd send and reply Sargun Dhillon
2021-05-17 19:39 ` [PATCH v2 1/4] Documentation: seccomp: Fix user notification documentation Sargun Dhillon
2021-05-17 19:39 ` [PATCH v2 2/4] seccomp: Refactor notification handler to prepare for new semantics Sargun Dhillon
2021-05-25 16:03 ` Rodrigo Campos
2021-05-25 20:44 ` Sargun Dhillon
2021-05-27 11:51 ` Rodrigo Campos
2021-05-27 18:41 ` Kees Cook
2021-05-28 15:27 ` Rodrigo Campos
2021-05-28 16:50 ` Kees Cook
2021-05-28 17:14 ` Kees Cook
2021-05-28 22:31 ` Rodrigo Campos
2021-06-01 19:22 ` Kees Cook
2021-05-17 19:39 ` [PATCH v2 3/4] seccomp: Support atomic "addfd + send reply" Sargun Dhillon
2021-05-21 15:45 ` Christian Brauner [this message]
2021-05-17 19:39 ` [PATCH v2 4/4] selftests/seccomp: Add test for atomic addfd+send Sargun Dhillon
2021-05-18 16:45 ` [PATCH v2 0/4] Atomic addfd send and reply Andy Lutomirski
2021-05-21 15:44 ` Christian Brauner
2021-05-27 2:43 ` Kees Cook
2022-07-19 2:11 [PATCH v2 3/4] seccomp: Support atomic "addfd + send reply" Robin Naccari
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=20210521154532.utttvofngdg6qeob@wittgenstein \
--to=christian.brauner@ubuntu.com \
--cc=containers@lists.linux.dev \
--cc=gscrivan@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mauricio@kinvolk.io \
--cc=mic@linux.microsoft.com \
--cc=rodrigo@kinvolk.io \
--cc=sargun@sargun.me \
--cc=tycho@tycho.pizza \
/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
all inboxes | Powered by JetHome®