From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Weimer Subject: Re: Detecting the availability of VSYSCALL Date: Wed, 26 Jun 2019 18:45:08 +0200 Message-ID: <87sgrw1ejv.fsf@oldenburg2.str.redhat.com> References: <87v9wty9v4.fsf@oldenburg2.str.redhat.com> <87lfxpy614.fsf@oldenburg2.str.redhat.com> <87a7e5v1d9.fsf@oldenburg2.str.redhat.com> <87o92kmtp5.fsf@oldenburg2.str.redhat.com> <87r27gjss3.fsf@oldenburg2.str.redhat.com> <534B9F63-E949-4CF5-ACAC-71381190846F@amacapital.net> <87a7e4jr4s.fsf@oldenburg2.str.redhat.com> <6CECE9DE-51AB-4A21-A257-8B85C4C94EB0@amacapital.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: <6CECE9DE-51AB-4A21-A257-8B85C4C94EB0@amacapital.net> (Andy Lutomirski's message of "Wed, 26 Jun 2019 09:24:38 -0700") To: Andy Lutomirski Cc: Andy Lutomirski , Thomas Gleixner , Linux API , Kernel Hardening , linux-x86_64@vger.kernel.org, linux-arch , Kees Cook , Carlos O'Donell , X86 ML List-Id: linux-arch.vger.kernel.org * Andy Lutomirski: > Can=E2=80=99t 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? >>=20 >> 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. >>=20 >> 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. >>=20 >> My guess is that it would be easier to have a personality flag. Then >> they could keep the host largely as-is, and would =E2=80=9Conly=E2=80=9D= 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=E2=80=99t scream =E2=80=9Cexploit me=E2=80=9D while preser= ving 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:34346 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbfFZQpT (ORCPT ); Wed, 26 Jun 2019 12:45:19 -0400 From: Florian Weimer Subject: Re: Detecting the availability of VSYSCALL References: <87v9wty9v4.fsf@oldenburg2.str.redhat.com> <87lfxpy614.fsf@oldenburg2.str.redhat.com> <87a7e5v1d9.fsf@oldenburg2.str.redhat.com> <87o92kmtp5.fsf@oldenburg2.str.redhat.com> <87r27gjss3.fsf@oldenburg2.str.redhat.com> <534B9F63-E949-4CF5-ACAC-71381190846F@amacapital.net> <87a7e4jr4s.fsf@oldenburg2.str.redhat.com> <6CECE9DE-51AB-4A21-A257-8B85C4C94EB0@amacapital.net> Date: Wed, 26 Jun 2019 18:45:08 +0200 In-Reply-To: <6CECE9DE-51AB-4A21-A257-8B85C4C94EB0@amacapital.net> (Andy Lutomirski's message of "Wed, 26 Jun 2019 09:24:38 -0700") Message-ID: <87sgrw1ejv.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andy Lutomirski Cc: Andy Lutomirski , Thomas Gleixner , Linux API , Kernel Hardening , linux-x86_64@vger.kernel.org, linux-arch , Kees Cook , Carlos O'Donell , X86 ML Message-ID: <20190626164508.FPD9i0zLn2hXKP0szSUIP289sqcsL4GGrQNqRpInpqE@z> * 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