From: Aleksa Sarai <cyphar@cyphar.com> To: Jeff Layton <jlayton@kernel.org> Cc: "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>, "Florian Weimer" <fweimer@redhat.com>, "Mickaël Salaün" <mic@digikod.net>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "Andy Lutomirski" <luto@kernel.org>, "Christian Heimes" <christian@python.org>, "Daniel Borkmann" <daniel@iogearbox.net>, "Eric Chiang" <ericchiang@google.com>, "James Morris" <jmorris@namei.org>, "Jan Kara" <jack@suse.cz>, "Jann Horn" <jannh@google.com>, "Jonathan Corbet" <corbet@lwn.net>, "Kees Cook" <keescook@chromium.org>, "Matthew Garrett" <mjg59@google.com>, "Matthew Wilcox" <willy@infradead.org>, "Michael Kerrisk" <mtk.manpages@gmail.com>, "Mimi Zohar" <zohar@linux.ibm.com>, "Philippe Trébuchet" <philippe.trebuchet@ssi.gouv.fr>, "Scott Shell" <scottsh@microsoft.com>, "Sean Christopherson" <sean.j.christopherson@intel.com>, "Shuah Khan" <shuah@kernel.org>, "Song Liu" <songliubraving@fb.com>, "Steve Dower" <steve.dower@python.org>, "Steve Grubb" <sgrubb@redhat.com>, "Thibaut Sautereau" <thibaut.sautereau@ssi.gouv.fr>, "Vincent Strubel" <vincent.strubel@ssi.gouv.fr>, "Yves-Alexis Perez" <yves-alexis.perez@ssi.gouv.fr>, kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Date: Sat, 7 Sep 2019 03:13:35 +1000 [thread overview] Message-ID: <20190906171335.d7mc3no5tdrcn6r5@yavin.dot.cyphar.com> (raw) In-Reply-To: <f53ec45fd253e96d1c8d0ea6f9cca7f68afa51e3.camel@kernel.org> [-- Attachment #1: Type: text/plain, Size: 1776 bytes --] On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote: > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote: > > On 06/09/2019 17:56, Florian Weimer wrote: > > > Let's assume I want to add support for this to the glibc dynamic loader, > > > while still being able to run on older kernels. > > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails > > > with EINVAL, try again without O_MAYEXEC? > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for > > older kernel to use O_MAYEXEC. > > > > Well...maybe. What about existing programs that are sending down bogus > open flags? Once you turn this on, they may break...or provide a way to > circumvent the protections this gives. It should be noted that this has been a valid concern for every new O_* flag introduced (and yet we still introduced new flags, despite the concern) -- though to be fair, O_TMPFILE actually does have a work-around with the O_DIRECTORY mask setup. The openat2() set adds O_EMPTYPATH -- though in fairness it's also backwards compatible because empty path strings have always given ENOENT (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings. > Maybe this should be a new flag that is only usable in the new openat2() > syscall that's still under discussion? That syscall will enforce that > all flags are recognized. You presumably wouldn't need the sysctl if you > went that route too. I'm also interested in whether we could add an UPGRADE_NOEXEC flag to how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for it, since I'd heard about this work through the grape-vine). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Aleksa Sarai <cyphar@cyphar.com> To: Jeff Layton <jlayton@kernel.org> Cc: "Mickaël Salaün" <mickael.salaun@ssi.gouv.fr>, "Florian Weimer" <fweimer@redhat.com>, "Mickaël Salaün" <mic@digikod.net>, linux-kernel@vger.kernel.org, "Alexei Starovoitov" <ast@kernel.org>, "Al Viro" <viro@zeniv.linux.org.uk>, "Andy Lutomirski" <luto@kernel.org>, "Christian Heimes" <christian@python.org>, "Daniel Borkmann" <daniel@iogearbox.net>, "Eric Chiang" <ericchiang@google.com>, "James Morris" <jmorris@namei.org>, "Jan Kara" <jack@suse.cz>, "Jann Horn" <jannh@google.com>, "Jonathan Corbet" <corbet@lwn.net>, "Kees Cook" <keescook@chromium.org>, "Matthew Garrett" <mjg59@google.com>, "Matthew Wilcox" <willy@infradead.org>, "Michael Kerrisk" <mtk.manpages@gmail.com>, "Mimi Zohar" <zohar@linux.ibm.com> Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Date: Sat, 7 Sep 2019 03:13:35 +1000 [thread overview] Message-ID: <20190906171335.d7mc3no5tdrcn6r5@yavin.dot.cyphar.com> (raw) In-Reply-To: <f53ec45fd253e96d1c8d0ea6f9cca7f68afa51e3.camel@kernel.org> [-- Attachment #1: Type: text/plain, Size: 1776 bytes --] On 2019-09-06, Jeff Layton <jlayton@kernel.org> wrote: > On Fri, 2019-09-06 at 18:06 +0200, Mickaël Salaün wrote: > > On 06/09/2019 17:56, Florian Weimer wrote: > > > Let's assume I want to add support for this to the glibc dynamic loader, > > > while still being able to run on older kernels. > > > > > > Is it safe to try the open call first, with O_MAYEXEC, and if that fails > > > with EINVAL, try again without O_MAYEXEC? > > > > The kernel ignore unknown open(2) flags, so yes, it is safe even for > > older kernel to use O_MAYEXEC. > > > > Well...maybe. What about existing programs that are sending down bogus > open flags? Once you turn this on, they may break...or provide a way to > circumvent the protections this gives. It should be noted that this has been a valid concern for every new O_* flag introduced (and yet we still introduced new flags, despite the concern) -- though to be fair, O_TMPFILE actually does have a work-around with the O_DIRECTORY mask setup. The openat2() set adds O_EMPTYPATH -- though in fairness it's also backwards compatible because empty path strings have always given ENOENT (or EINVAL?) while O_EMPTYPATH is a no-op non-empty strings. > Maybe this should be a new flag that is only usable in the new openat2() > syscall that's still under discussion? That syscall will enforce that > all flags are recognized. You presumably wouldn't need the sysctl if you > went that route too. I'm also interested in whether we could add an UPGRADE_NOEXEC flag to how->upgrade_mask for the openat2(2) patchset (I reserved a flag bit for it, since I'd heard about this work through the grape-vine). -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2019-09-06 17:14 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-06 15:24 [PATCH v2 0/5] Add support for O_MAYEXEC Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 15:24 ` [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open() Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 15:56 ` Florian Weimer 2019-09-06 15:56 ` Florian Weimer 2019-09-06 16:06 ` Mickaël Salaün 2019-09-06 16:06 ` Mickaël Salaün 2019-09-06 16:48 ` Jeff Layton 2019-09-06 16:48 ` Jeff Layton 2019-09-06 17:13 ` Aleksa Sarai [this message] 2019-09-06 17:13 ` Aleksa Sarai 2019-09-06 19:43 ` Jeff Layton 2019-09-06 19:43 ` Jeff Layton 2019-09-06 20:06 ` Andy Lutomirski 2019-09-06 20:06 ` Andy Lutomirski 2019-09-06 20:51 ` Jeff Layton 2019-09-06 20:51 ` Jeff Layton 2019-09-06 21:27 ` Andy Lutomirski 2019-09-06 21:27 ` Andy Lutomirski 2019-09-06 22:12 ` Aleksa Sarai 2019-09-06 22:12 ` Aleksa Sarai 2019-09-09 9:33 ` Mickaël Salaün 2019-09-09 9:33 ` Mickaël Salaün 2019-09-06 22:05 ` Aleksa Sarai 2019-09-06 22:05 ` Aleksa Sarai 2019-09-06 22:18 ` Aleksa Sarai 2019-09-06 22:18 ` Aleksa Sarai 2019-09-06 17:14 ` Mickaël Salaün 2019-09-06 17:14 ` Mickaël Salaün 2019-09-06 18:38 ` Jeff Layton 2019-09-06 18:38 ` Jeff Layton 2019-09-06 18:41 ` Andy Lutomirski 2019-09-06 18:41 ` Andy Lutomirski 2019-09-09 9:18 ` Mickaël Salaün 2019-09-09 9:18 ` Mickaël Salaün 2019-09-09 15:49 ` Andy Lutomirski 2019-09-09 15:49 ` Andy Lutomirski 2019-09-06 18:44 ` Florian Weimer 2019-09-06 18:44 ` Florian Weimer 2019-09-06 19:03 ` James Morris 2019-09-06 19:03 ` James Morris 2019-09-09 9:25 ` Mickaël Salaün 2019-09-09 9:25 ` Mickaël Salaün 2019-09-09 10:12 ` James Morris 2019-09-09 10:12 ` James Morris 2019-09-09 10:54 ` Mickaël Salaün 2019-09-09 10:54 ` Mickaël Salaün 2019-09-09 12:28 ` Aleksa Sarai 2019-09-09 12:28 ` Aleksa Sarai 2019-09-09 12:33 ` Mickaël Salaün 2019-09-09 12:33 ` Mickaël Salaün 2019-09-09 11:54 ` Aleksa Sarai 2019-09-09 11:54 ` Aleksa Sarai 2019-09-09 12:28 ` Mickaël Salaün 2019-09-09 12:28 ` Mickaël Salaün 2019-09-06 17:07 ` Aleksa Sarai 2019-09-06 17:07 ` Aleksa Sarai 2019-09-06 17:20 ` Christian Brauner 2019-09-06 17:20 ` Christian Brauner 2019-09-06 17:24 ` Mickaël Salaün 2019-09-06 17:24 ` Mickaël Salaün 2019-09-06 17:40 ` Tycho Andersen 2019-09-06 17:40 ` Tycho Andersen 2019-09-06 18:27 ` Florian Weimer 2019-09-06 18:27 ` Florian Weimer 2019-09-06 18:46 ` Tycho Andersen 2019-09-06 18:46 ` Tycho Andersen 2019-09-06 15:24 ` [PATCH v2 2/5] fs: Add a MAY_EXECMOUNT flag to infer the noexec mount propertie Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 15:24 ` [PATCH v2 3/5] fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 15:24 ` [PATCH v2 4/5] selftest/exec: Add tests for O_MAYEXEC enforcing Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 15:24 ` [PATCH v2 5/5] doc: Add documentation for the fs.open_mayexec_enforce sysctl Mickaël Salaün 2019-09-06 15:24 ` Mickaël Salaün 2019-09-06 18:50 ` [PATCH v2 0/5] Add support for O_MAYEXEC Steve Grubb 2019-09-06 18:50 ` Steve Grubb 2019-09-06 18:57 ` Florian Weimer 2019-09-06 18:57 ` Florian Weimer 2019-09-06 19:07 ` Steve Grubb 2019-09-06 19:07 ` Steve Grubb 2019-09-06 19:26 ` Andy Lutomirski 2019-09-06 19:26 ` Andy Lutomirski 2019-09-06 22:44 ` Aleksa Sarai 2019-09-06 22:44 ` Aleksa Sarai 2019-09-09 9:09 ` Mickaël Salaün 2019-09-09 9:09 ` Mickaël Salaün 2019-09-09 0:16 ` James Morris 2019-09-09 0:16 ` James Morris
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=20190906171335.d7mc3no5tdrcn6r5@yavin.dot.cyphar.com \ --to=cyphar@cyphar.com \ --cc=ast@kernel.org \ --cc=christian@python.org \ --cc=corbet@lwn.net \ --cc=daniel@iogearbox.net \ --cc=ericchiang@google.com \ --cc=fweimer@redhat.com \ --cc=jack@suse.cz \ --cc=jannh@google.com \ --cc=jlayton@kernel.org \ --cc=jmorris@namei.org \ --cc=keescook@chromium.org \ --cc=kernel-hardening@lists.openwall.com \ --cc=linux-api@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mic@digikod.net \ --cc=mickael.salaun@ssi.gouv.fr \ --cc=mjg59@google.com \ --cc=mtk.manpages@gmail.com \ --cc=philippe.trebuchet@ssi.gouv.fr \ --cc=scottsh@microsoft.com \ --cc=sean.j.christopherson@intel.com \ --cc=sgrubb@redhat.com \ --cc=shuah@kernel.org \ --cc=songliubraving@fb.com \ --cc=steve.dower@python.org \ --cc=thibaut.sautereau@ssi.gouv.fr \ --cc=vincent.strubel@ssi.gouv.fr \ --cc=viro@zeniv.linux.org.uk \ --cc=willy@infradead.org \ --cc=yves-alexis.perez@ssi.gouv.fr \ --cc=zohar@linux.ibm.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: linkBe 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.