Date: Wed, 9 Jan 2019 14:41:12 +0100 From: Mickaël Salaün <mickael.salaun@....gouv.fr> To: Kees Cook <keescook@...omium.org>, Al Viro <viro@...iv.linux.org.uk>, James Morris <jmorris@...ei.org> CC: Jann Horn <jannh@...gle.com>, Mickaël Salaün <mic@...ikod.net>, kernel list <linux-kernel@...r.kernel.org>, Jonathan Corbet <corbet@....net>, Matthew Garrett <mjg59@...gle.com>, Michael Kerrisk-manpages <mtk.manpages@...il.com>, Mimi Zohar <zohar@...ux.ibm.com>, <philippe.trebuchet@....gouv.fr>, Shuah Khan <shuah@...nel.org>, <thibaut.sautereau@....gouv.fr>, <vincent.strubel@....gouv.fr>, Perez Yves-Alexis <yves-alexis.perez@....gouv.fr>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Linux API <linux-api@...r.kernel.org>, linux-security-module <linux-security-module@...r.kernel.org>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, Andy Lutomirski <luto@...nel.org> Subject: Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC On 09/01/2019 00:30, Kees Cook wrote: > On Tue, Jan 8, 2019 at 5:29 AM Mickaël Salaün > <mickael.salaun@....gouv.fr> wrote: >> >> >> On 03/01/2019 12:17, Jann Horn wrote: >>> On Thu, Dec 13, 2018 at 3:49 PM Mickaël Salaün >>> <mickael.salaun@....gouv.fr> wrote: >>>> On 12/12/2018 18:09, Jann Horn wrote: >>>>> On Wed, Dec 12, 2018 at 9:18 AM Mickaël Salaün <mic@...ikod.net> wrote: >>>>>> Enable to either propagate the mount options from the underlying VFS >>>>>> mount to prevent execution, or to propagate the file execute permission. >>>>>> This may allow a script interpreter to check execution permissions >>>>>> before reading commands from a file. >>>>>> >>>>>> The main goal is to be able to protect the kernel by restricting >>>>>> arbitrary syscalls that an attacker could perform with a crafted binary >>>>>> or certain script languages. It also improves multilevel isolation >>>>>> by reducing the ability of an attacker to use side channels with >>>>>> specific code. These restrictions can natively be enforced for ELF >>>>>> binaries (with the noexec mount option) but require this kernel >>>>>> extension to properly handle scripts (e.g., Python, Perl). > > I like this idea, but I think it shouldn't live in Yama (since it is > currently intended to be a ptrace-policy-only LSM). It was > _originally_ designed to do various DAC improvements, but the > agreement was that those should live directly in the VFS instead (i.e. > the symlink, hardlink and now fifo and regular file defenses). > > This should likely go in similarly. (But if not, it could also be its own LSM.) > I think that Yama is quite handy and make sense here, but I'm fine putting this knob elsewhere. However, I was thinking, for a future patch series, to add another sysctl to lock this choice, i.e. generalizing the way Yama can lock the ptrace_scope. What matter here is the ability for an LSM to use this O_MAYEXEC flag. Yama is a good place to showcase this feature and I think it is cleaner to leverage the LSM framework to put new (optional) security features. I can easily create a new LSM but it would be pretty similar to Yama... What do you think about it James and Al? Side question: wouldn't it be better to use a 0600 mode (instead of 0644) for this kind of sysctl?
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.