Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 9 Sep 2019 08:49:32 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Mickaël Salaün <mickael.salaun@....gouv.fr>
Cc: Jeff Layton <jlayton@...nel.org>, Florian Weimer <fweimer@...hat.com>,
 Mickaël Salaün <mic@...ikod.net>,
 linux-kernel@...r.kernel.org, Aleksa Sarai <cyphar@...har.com>,
 Alexei Starovoitov <ast@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
 Andy Lutomirski <luto@...nel.org>, Christian Heimes <christian@...hon.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 Eric Chiang <ericchiang@...gle.com>, James Morris <jmorris@...ei.org>,
 Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>,
 Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>,
 Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>,
 Michael Kerrisk <mtk.manpages@...il.com>, Mimi Zohar <zohar@...ux.ibm.com>,
 Philippe Trébuchet <philippe.trebuchet@....gouv.fr>,
 Scott Shell <scottsh@...rosoft.com>,
 Sean Christopherson <sean.j.christopherson@...el.com>,
 Shuah Khan <shuah@...nel.org>, Song Liu <songliubraving@...com>,
 Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>,
 Thibaut Sautereau <thibaut.sautereau@....gouv.fr>,
 Vincent Strubel <vincent.strubel@....gouv.fr>,
 Yves-Alexis Perez <yves-alexis.perez@....gouv.fr>,
 kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
 linux-security-module@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 1/5] fs: Add support for an O_MAYEXEC flag on sys_open()


> On Sep 9, 2019, at 2:18 AM, Mickaël Salaün <mickael.salaun@....gouv.fr> wrote:
> 
> 
>> On 06/09/2019 20:41, Andy Lutomirski wrote:
>> 
>> 
>>>> On Sep 6, 2019, at 11:38 AM, Jeff Layton <jlayton@...nel.org> wrote:
>>>> 
>>>>> On Fri, 2019-09-06 at 19:14 +0200, Mickaël Salaün wrote:
>>>>>> On 06/09/2019 18:48, Jeff Layton 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.
>>>> 
>>>> Well, I don't think we should nor could care about bogus programs that
>>>> do not conform to the Linux ABI.
>>>> 
>>> 
>>> But they do conform. The ABI is just undefined here. Unknown flags are
>>> ignored so we never really know if $random_program may be setting them.
>>> 
>>>>> 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.
>>>> 
>>>> Here is a thread about a new syscall:
>>>> https://lore.kernel.org/lkml/1544699060.6703.11.camel@linux.ibm.com/
>>>> 
>>>> I don't think it fit well with auditing nor integrity. Moreover using
>>>> the current open(2) behavior of ignoring unknown flags fit well with the
>>>> usage of O_MAYEXEC (because it is only a hint to the kernel about the
>>>> use of the *opened* file).
>>>> 
>>> 
>>> The fact that open and openat didn't vet unknown flags is really a bug.
>>> 
>>> Too late to fix it now, of course, and as Aleksa points out, we've
>>> worked around that in the past. Now though, we have a new openat2
>>> syscall on the horizon. There's little need to continue these sorts of
>>> hacks.
>>> 
>>> New open flags really have no place in the old syscalls, IMO.
>>> 
>>>>> Anyone that wants to use this will have to recompile anyway. If the
>>>>> kernel doesn't support openat2 or if the flag is rejected then you know
>>>>> that you have no O_MAYEXEC support and can decide what to do.
>>>> 
>>>> If we want to enforce a security policy, we need to either be the system
>>>> administrator or the distro developer. If a distro ship interpreters
>>>> using this flag, we don't need to recompile anything, but we need to be
>>>> able to control the enforcement according to the mount point
>>>> configuration (or an advanced MAC, or an IMA config). I don't see why an
>>>> userspace process should check if this flag is supported or not, it
>>>> should simply use it, and the sysadmin will enable an enforcement if it
>>>> makes sense for the whole system.
>>>> 
>>> 
>>> A userland program may need to do other risk mitigation if it sets
>>> O_MAYEXEC and the kernel doesn't recognize it.
>>> 
>>> Personally, here's what I'd suggest:
>>> 
>>> - Base this on top of the openat2 set
>>> - Change it that so that openat2() files are non-executable by default. Anyone wanting to do that needs to set O_MAYEXEC or upgrade the fd somehow.
>>> - Only have the openat2 syscall pay attention to O_MAYEXEC. Let open and openat continue ignoring the new flag.
>>> 
>>> That works around a whole pile of potential ABI headaches. Note that
>>> we'd need to make that decision before the openat2 patches are merged.
>>> 
>>> Even better would be to declare the new flag in some openat2-only flag
>>> space, so there's no confusion about it being supported by legacy open
>>> calls.
>>> 
>>> If glibc wants to implement an open -> openat2 wrapper in userland
>>> later, it can set that flag in the wrapper implicitly to emulate the old
>>> behavior.
>>> 
>>> Given that you're going to have to recompile software to take advantage
>>> of this anyway, what's the benefit to changing legacy syscalls?
>>> 
>>>>>>> Or do I risk disabling this security feature if I do that?
>>>>>> 
>>>>>> It is only a security feature if the kernel support it, otherwise it is
>>>>>> a no-op.
>>>>>> 
>>>>> 
>>>>> With a security feature, I think we really want userland to aware of
>>>>> whether it works.
>>>> 
>>>> If userland would like to enforce something, it can already do it
>>>> without any kernel modification. The goal of the O_MAYEXEC flag is to
>>>> enable the kernel, hence sysadmins or system designers, to enforce a
>>>> global security policy that makes sense.
>>>> 
>>> 
>>> I don't see how this helps anything if you can't tell whether the kernel
>>> recognizes the damned thing. Also, our track record with global sysctl
>>> switches like this is pretty poor. They're an administrative headache as
>>> well as a potential attack vector.
>> 
>> I tend to agree. The sysctl seems like it’s asking for trouble. I can see an ld.so.conf option to turn this thing off making sense.
> 
> The sysctl is required to enable the adoption of this flag without
> breaking existing systems. Current systems may have "noexec" on mount
> points containing scripts. Without giving the ability to the sysadmin to
> control that behavior, updating to a newer version of an interpreter
> using O_MAYEXEC may break such systems.
> 
> How would you do this with ld.so.conf ?
> 

By telling user code not to use O_MAYEXEC?

Alternatively, you could allow O_MAYEXEC even on a noexec mount and have a strong_noexec option that blocks it.

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.