linux-api.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Jann Horn <jannh@google.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Christoph Hellwig <hch@infradead.org>,
	Kees Cook <keescook@chromium.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Drewry <wad@chromium.org>, Mark Wielaard <mark@klomp.org>,
	Christian Brauner <christian.brauner@ubuntu.com>,
	Linux API <linux-api@vger.kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	kernel list <linux-kernel@vger.kernel.org>,
	dev@opencontainers.org, Jonathan Corbet <corbet@lwn.net>,
	"Carlos O'Donell" <carlos@redhat.com>
Subject: Re: [PATCH] syscalls: Document OCI seccomp filter interactions & workaround
Date: Tue, 24 Nov 2020 19:17:00 +0100	[thread overview]
Message-ID: <87h7pezkkj.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <CAG48ez2NH2Esw_55JiwK1FAzr_qFFyGaPrE_A=iH=dNuVvY6GQ@mail.gmail.com> (Jann Horn's message of "Tue, 24 Nov 2020 18:30:28 +0100")

* Jann Horn:

> But if you can't tell whether the more modern syscall failed because
> of a seccomp filter, you may be forced to retry with an older syscall
> even on systems where the new syscall works fine, and such a fallback
> may reduce security or reliability if you're trying to use some flags
> that only the new syscall provides for security, or something like
> that. (As a contrived example, imagine being forced to retry any
> tgkill() that fails with EPERM as a tkill() just in case you're
> running under a seccomp filter.)

We have exactly this situation with faccessat2 and faccessat today.
EPERM could mean a reject from a LSM, and we really don't want to do our
broken fallback in this case because it will mask the EPERM error from
the LSM (and the sole purpose of faccessat2 is to get that error).

This is why I was so eager to start using faccessat2 in glibc, and we
are now encountering breakage with container runtimes.  Applications
call faccessat (with a non-zero flags argument) today, and they now get
routed to the faccessat2 entry point, without needing recompilation or
anything like that.

We have the same problem for any new system call, but it's different
this time because it affects 64-bit hosts *and* existing applications.

And as I explained earlier, I want to take this opportunity to get
consensus how to solve this properly, so that we are ready for a new
system call where incorrect fallback would definitely reintroduce a
security issue.  Whether it's that ugly probing sequence, a change to
the OCI specification that gets deployed in a reasonable time frame, or
something else that I haven't thought of—I do not have a very strong
preference, although I lean towards the spec change myself.  But I do
feel that we shouldn't throw in a distro-specific patch to paper over
the current faccessat2 issue and forget about it.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


  parent reply	other threads:[~2020-11-24 18:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-24 12:08 [PATCH] syscalls: Document OCI seccomp filter interactions & workaround Florian Weimer
2020-11-24 12:26 ` Christian Brauner
2020-11-24 12:54   ` Florian Weimer
2020-11-24 14:08     ` Mark Wielaard
2020-11-24 16:45       ` Christoph Hellwig
2020-11-24 17:06         ` Jann Horn
2020-11-24 17:15           ` Greg KH
2020-11-24 17:21             ` Christian Brauner
2020-11-24 17:30             ` Jann Horn
2020-11-24 17:44               ` Greg KH
2020-11-24 17:47                 ` Jann Horn
2020-11-24 18:17               ` Florian Weimer [this message]
2020-11-24 18:02           ` Florian Weimer
2020-11-24 18:09       ` Florian Weimer
2020-11-24 12:58 ` Aleksa Sarai
2020-11-24 13:05   ` Florian Weimer
2020-11-24 13:37 ` Christoph Hellwig
2020-11-24 14:08   ` Florian Weimer
2020-11-24 16:46     ` Christoph Hellwig
2020-11-24 16:52       ` Florian Weimer

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=87h7pezkkj.fsf@oldenburg2.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=carlos@redhat.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=corbet@lwn.net \
    --cc=dev@opencontainers.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mark@klomp.org \
    --cc=wad@chromium.org \
    /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).