[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sgrw1ejv.fsf@oldenburg2.str.redhat.com>
Date: Wed, 26 Jun 2019 18:45:08 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
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
* Andy Lutomirski:
> Can’t an ELF note be done with some more or less ordinary asm such
> that any link editor will insert it correctly?
We've just been over this for the CET enablement. ELF PT_NOTE parsing
was rejected there.
I don't think binutils ld has a way to set an ELF program header it
doesn't know anything about.
>>> 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.
Are restrictive personality flags still a problem with user namespaces?
I think it would be fine to restrict this one to CAP_SYS_ADMIN.
Thanks,
Florian
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.
