Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Will Drewry <wad@chromium.org>
To: Kees Cook <keescook@chromium.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Sargun Dhillon <sargun@sargun.me>,
	Matt Denton <mpdenton@google.com>,
	Christian Brauner <christian@brauner.io>,
	Tycho Andersen <tycho@tycho.ws>,
	David Laight <David.Laight@aculab.com>,
	Christoph Hellwig <hch@lst.de>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Aleksa Sarai <cyphar@cyphar.com>, Jann Horn <jannh@google.com>,
	Chris Palmer <palmer@google.com>,
	Robert Sesek <rsesek@google.com>,
	Giuseppe Scrivano <gscrivan@redhat.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Shuah Khan <shuah@kernel.org>,
	netdev@vger.kernel.org, containers@lists.linux-foundation.org,
	linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v7 8/9] seccomp: Introduce addfd ioctl to seccomp user notifier
Date: Tue, 14 Jul 2020 13:20:08 -0500	[thread overview]
Message-ID: <CAAFS_9Gx1=ytAqTPE3ygh6euJqDObcdg70-gzUuq3eHeWHR2HQ@mail.gmail.com> (raw)
In-Reply-To: <20200709182642.1773477-9-keescook@chromium.org>

On Thu, Jul 9, 2020 at 1:26 PM Kees Cook <keescook@chromium.org> wrote:
>
> From: Sargun Dhillon <sargun@sargun.me>
>
> The current SECCOMP_RET_USER_NOTIF API allows for syscall supervision over
> an fd. It is often used in settings where a supervising task emulates
> syscalls on behalf of a supervised task in userspace, either to further
> restrict the supervisee's syscall abilities or to circumvent kernel
> enforced restrictions the supervisor deems safe to lift (e.g. actually
> performing a mount(2) for an unprivileged container).
>
> While SECCOMP_RET_USER_NOTIF allows for the interception of any syscall,
> only a certain subset of syscalls could be correctly emulated. Over the
> last few development cycles, the set of syscalls which can't be emulated
> has been reduced due to the addition of pidfd_getfd(2). With this we are
> now able to, for example, intercept syscalls that require the supervisor
> to operate on file descriptors of the supervisee such as connect(2).
>
> However, syscalls that cause new file descriptors to be installed can not
> currently be correctly emulated since there is no way for the supervisor
> to inject file descriptors into the supervisee. This patch adds a
> new addfd ioctl to remove this restriction by allowing the supervisor to
> install file descriptors into the intercepted task. By implementing this
> feature via seccomp the supervisor effectively instructs the supervisee
> to install a set of file descriptors into its own file descriptor table
> during the intercepted syscall. This way it is possible to intercept
> syscalls such as open() or accept(), and install (or replace, like
> dup2(2)) the supervisor's resulting fd into the supervisee. One
> replacement use-case would be to redirect the stdout and stderr of a
> supervisee into log file descriptors opened by the supervisor.
>
> The ioctl handling is based on the discussions[1] of how Extensible
> Arguments should interact with ioctls. Instead of building size into
> the addfd structure, make it a function of the ioctl command (which
> is how sizes are normally passed to ioctls). To support forward and
> backward compatibility, just mask out the direction and size, and match
> everything. The size (and any future direction) checks are done along
> with copy_struct_from_user() logic.
>
> As a note, the seccomp_notif_addfd structure is laid out based on 8-byte
> alignment without requiring packing as there have been packing issues
> with uapi highlighted before[2][3]. Although we could overload the
> newfd field and use -1 to indicate that it is not to be used, doing
> so requires changing the size of the fd field, and introduces struct
> packing complexity.
>
> [1]: https://lore.kernel.org/lkml/87o8w9bcaf.fsf@mid.deneb.enyo.de/
> [2]: https://lore.kernel.org/lkml/a328b91d-fd8f-4f27-b3c2-91a9c45f18c0@rasmusvillemoes.dk/
> [3]: https://lore.kernel.org/lkml/20200612104629.GA15814@ircssh-2.c.rugged-nimbus-611.internal
>
> Suggested-by: Matt Denton <mpdenton@google.com>
> Link: https://lore.kernel.org/r/20200603011044.7972-4-sargun@sargun.me
> Signed-off-by: Sargun Dhillon <sargun@sargun.me>
> Co-developed-by: Kees Cook <keescook@chromium.org>
> Signed-off-by: Kees Cook <keescook@chromium.org>

Reviewed-by: Will Drewry <wad@chromium.org>

  reply	other threads:[~2020-07-14 18:20 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 18:26 [PATCH v7 0/9] Add seccomp notifier ioctl that enables adding fds Kees Cook
2020-07-09 18:26 ` [PATCH v7 1/9] net/compat: Add missing sock updates for SCM_RIGHTS Kees Cook
2020-07-10 11:28   ` Christian Brauner
2020-07-09 18:26 ` [PATCH v7 2/9] pidfd: Add missing sock updates for pidfd_getfd() Kees Cook
2020-07-09 20:00   ` Jann Horn
2020-07-09 21:17     ` Kees Cook
2020-07-09 22:35     ` Kees Cook
2020-07-09 18:26 ` [PATCH v7 3/9] net/scm: Regularize compat handling of scm_detach_fds() Kees Cook
2020-08-07 20:29   ` John Stultz
2020-08-07 22:18     ` Kees Cook
2020-08-08  0:02       ` John Stultz
2020-08-08  7:17         ` Kees Cook
2020-07-09 18:26 ` [PATCH v7 4/9] fs: Move __scm_install_fd() to __receive_fd() Kees Cook
2020-07-09 18:26 ` [PATCH v7 5/9] fs: Add receive_fd() wrapper for __receive_fd() Kees Cook
2020-07-09 18:26 ` [PATCH v7 6/9] pidfd: Replace open-coded receive_fd() Kees Cook
2020-07-09 18:26 ` [PATCH v7 7/9] fs: Expand __receive_fd() to accept existing fd Kees Cook
2020-07-09 18:26 ` [PATCH v7 8/9] seccomp: Introduce addfd ioctl to seccomp user notifier Kees Cook
2020-07-14 18:20   ` Will Drewry [this message]
2020-07-09 18:26 ` [PATCH v7 9/9] selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD Kees Cook

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='CAAFS_9Gx1=ytAqTPE3ygh6euJqDObcdg70-gzUuq3eHeWHR2HQ@mail.gmail.com' \
    --to=wad@chromium.org \
    --cc=David.Laight@aculab.com \
    --cc=christian@brauner.io \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=gscrivan@redhat.com \
    --cc=hch@lst.de \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mpdenton@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=palmer@google.com \
    --cc=rsesek@google.com \
    --cc=sargun@sargun.me \
    --cc=shuah@kernel.org \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [PATCH v7 8/9] seccomp: Introduce addfd ioctl to seccomp user notifier' \
    /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

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