[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <6CECE9DE-51AB-4A21-A257-8B85C4C94EB0@amacapital.net>
Date: Wed, 26 Jun 2019 09:24:38 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Florian Weimer <fweimer@...hat.com>
Cc: Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux API <linux-api@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>,
linux-x86_64@...r.kernel.org, linux-arch <linux-arch@...r.kernel.org>,
Kees Cook <keescook@...omium.org>, Carlos O'Donell <carlos@...hat.com>,
X86 ML <x86@...nel.org>
Subject: Re: Detecting the availability of VSYSCALL
> On Jun 26, 2019, at 8:36 AM, Florian Weimer <fweimer@...hat.com> wrote:
>
> * Andy Lutomirski:
>
>> I’m wondering if we can still do it: add a note or other ELF indicator
>> that says “I don’t need vsyscalls.” Then we can change the default
>> mode to “no vsyscalls if the flag is there, else execute-only
>> vsyscalls”.
>>
>> Would glibc go along with this?
>
> I think we can make it happen, at least for relatively recent glibc
> linked with current binutils. It's not trivial because it requires
> coordination among multiple projects. We have three or four widely used
> link editors now, but we could make it happen. (Although getting to
> PT_GNU_PROPERTY wasn't exactly easy.)
Can’t an ELF note be done with some more or less ordinary asm such that any link editor will insert it correctly?
>
>> Would enterprise distros consider backporting such a thing?
>
> Enterprise distros aren't the problem here because they can't remove
> vsyscall support for quite a while due to existing customer binaries.
> For them, it would just be an additional (and welcome) hardening
> opportunity.
>
> The challenge here are container hosting platforms which have already
> disabled vsyscall, presumably to protect the container host itself.
> They would need to rebuild the container host userspace with the markup
> to keep it protected, and then they could switch to a kernel which has
> vsyscall-unless-opt-out logic. That seems to be a bit of a stretch
> because from their perspective, there's no problem today.
>
> My guess is that it would be easier to have a personality flag. Then
> they could keep the host largely as-is, and would “only” need a
> mechanism to pass through the flag from the image metadata to the actual
> container creation. It's still a change to the container host (and the
> kernel change is required as well), but it would not require relinking
> every statically linked binary.
>
>
The problem with a personality flag is that it needs to have some kind of sensible behavior for setuid programs, and getting that right in a way that doesn’t scream “exploit me” while preserving useful compatibility may be tricky.
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.
