Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4396066yba; Tue, 7 May 2019 17:56:42 -0700 (PDT) X-Google-Smtp-Source: APXvYqwsILOAgUoySjaae6I5FqLMtS1x4mfAbP/2ZX+SHEOafBLfxWKgshKIwJ7qGPmlwM8TCNB1 X-Received: by 2002:a62:f247:: with SMTP id y7mr44554512pfl.18.1557277001941; Tue, 07 May 2019 17:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557277001; cv=none; d=google.com; s=arc-20160816; b=R4bmARcxbbvHV5HIWKfGA/ZRjME0SyPxthEtxr3km8tMMJgYlQezFK3VfCj3e/y2gs PxRTmLEswuAT1H3ckR30Xk0u6zgeub54yaYKk6uNrzEq4Y8rOCdX/KIsjH7c4N9LV7XH 38WcEX7KDip7GE0fGvQM8wIvZKiwSAAKE+LoQIyfK7wDCdTGnUkR021akxIqFvzOZFo5 OLARcXpvh1VZm1cwh/pTyNZe1iA525VoMH/0x+U8m1KgoC4D2QbbLRlFrzVc56e2Nl3H gQlTT7D+pk5ieZf25CsulIzRxN0KUrQiri5l1AgrNJSTwQzzbUsDbKYWbDmPTX4onww8 OHMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=kUD4Quv7zb6DCWmdlkXVj2piPN9jfJFa7MDJBoUqaew=; b=ajwDjOLMAWp4FuII6cuAdf+3//mvIHRuSPa+xhB0CcJ6S4Qn+7ksfJ8PQdVnNqORTf gs9wWmcPG9E8MJj0e2NhI5pb5S7oOQmPUinaQHKMddRBKcuxLZroSteWFWPurbTVusiQ homHe/PAyv5pZIDprbuxR9KvwfGB0JOSi/h9BhLqmB27UYukt+Rli+dum+slz3sE0qgJ 1e5Ymd58e4atwhuqhB60eKc71/SjHXc9GVMhCgRTuyTYZq2bb0ricd+72TMYyXaokReK Kh5Iy9BH21Br6tWnGP/wPLumtJKOR0YW6/qtgQOgv13tuSCet7c/2VFWSODxCydqB0XU Lw1Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b16si20348885pgb.501.2019.05.07.17.56.23; Tue, 07 May 2019 17:56:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726513AbfEHAza (ORCPT + 99 others); Tue, 7 May 2019 20:55:30 -0400 Received: from mx1.mailbox.org ([80.241.60.212]:15292 "EHLO mx1.mailbox.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726276AbfEHAza (ORCPT ); Tue, 7 May 2019 20:55:30 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 43F7D4DE51; Wed, 8 May 2019 02:55:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id aH1WSlgN_x_O; Wed, 8 May 2019 02:55:13 +0200 (CEST) Date: Wed, 8 May 2019 10:54:56 +1000 From: Aleksa Sarai To: Jann Horn Cc: Andy Lutomirski , Al Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , David Howells , Eric Biederman , Andrew Morton , Alexei Starovoitov , Kees Cook , Christian Brauner , Tycho Andersen , David Drysdale , Chanho Min , Oleg Nesterov , Aleksa Sarai , Linus Torvalds , containers@lists.linux-foundation.org, linux-fsdevel , Linux API , kernel list , linux-arch Subject: Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters Message-ID: <20190508005456.th5pkxljz536cq6w@yavin> References: <20190506165439.9155-1-cyphar@cyphar.com> <20190506165439.9155-6-cyphar@cyphar.com> <20190506191735.nmzf7kwfh7b6e2tf@yavin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m3sipayj4evvlhxl" Content-Disposition: inline In-Reply-To: <20190506191735.nmzf7kwfh7b6e2tf@yavin> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --m3sipayj4evvlhxl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-05-07, Aleksa Sarai wrote: > On 2019-05-06, Jann Horn wrote: > > On Mon, May 6, 2019 at 6:56 PM Aleksa Sarai wrote: > > > The need to be able to scope path resolution of interpreters became > > > clear with one of the possible vectors used in CVE-2019-5736 (which > > > most major container runtimes were vulnerable to). > > > > > > Naively, it might seem that openat(2) -- which supports path scoping = -- > > > can be combined with execveat(AT_EMPTY_PATH) to trivially scope the > > > binary being executed. Unfortunately, a "bad binary" (usually a symli= nk) > > > could be written as a #!-style script with the symlink target as the > > > interpreter -- which would be completely missed by just scoping the > > > openat(2). An example of this being exploitable is CVE-2019-5736. > > > > > > In order to get around this, we need to pass down to each binfmt_* > > > implementation the scoping flags requested in execveat(2). In order to > > > maintain backwards-compatibility we only pass the scoping AT_* flags. > > > > > > To avoid breaking userspace (in the exceptionally rare cases where you > > > have #!-scripts with a relative path being execveat(2)-ed with dfd != =3D > > > AT_FDCWD), we only pass dfd down to binfmt_* if any of our new flags = are > > > set in execveat(2). > >=20 > > This seems extremely dangerous. I like the overall series, but not this= patch. > >=20 > > > @@ -1762,6 +1774,12 @@ static int __do_execve_file(int fd, struct fil= ename *filename, > > > > > > sched_exec(); > > > > > > + bprm->flags =3D flags & (AT_XDEV | AT_NO_MAGICLINKS | AT_NO_S= YMLINKS | > > > + AT_THIS_ROOT); > > [...] > > > +#define AT_THIS_ROOT 0x100000 /* - Scope ".." resolution t= o dirfd (like chroot(2)). */ > >=20 > > So now what happens if there is a setuid root ELF binary with program > > interpreter "/lib64/ld-linux-x86-64.so.2" (like /bin/su), and an > > unprivileged user runs it with execveat(..., AT_THIS_ROOT)? Is that > > going to let the unprivileged user decide which interpreter the > > setuid-root process should use? From a high-level perspective, opening > > the interpreter should be controlled by the program that is being > > loaded, not by the program that invoked it. >=20 > I went a bit nuts with openat_exec(), and I did end up adding it to the > ELF interpreter lookup (and you're completely right that this is a bad > idea -- I will drop it from this patch if it's included in the next > series). >=20 > The proposed solutions you give below are much nicer than this patch so > I can drop it and work on fixing those issues separately. Another possible solution would be to only allow (for instance) AT_NO_MAGICLINKS for execveat(2). That way you cannot scope the resolution but you can block the most concerning cases -- those involving /proc-related access. I've posted a v7 with this patch dropped (because we can always add AT_* flags later in time), but I think having at least NO_MAGICLINKS would be useful. --=20 Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH --m3sipayj4evvlhxl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEb6Gz4/mhjNy+aiz1Snvnv3Dem58FAlzSKOAACgkQSnvnv3De m5+sVw//bA9Tf90p30BmnpG1nXFGi3o1Bvcw4bBtju6je0jL0EhCa6/D3MOOfYS3 6Hy2pArRB/bP7Q2EWPS9xcoB65JMLigAMxa2kMiNjbHW12fShWBidjFqMEVBM6cS mitc+utlJWYL0HYPOvyGz6POpDofulAvfiYBVgFeqlJA+/C3EvdEOAGTBCv705aM 7cNPTRJj+bcJ0Yvu6oXERxC+txG0AaM7CHeONhkZMxlkziZvwGyZYpui8pQgGm9D 6aMp++KpubhSiRZVq3XHEJtg1323ujlQBDW8Y2i5LtjizwXWCf1x+gj5yKbM7Yzt gVDcVDOrTfunC3DP9eiJtjVm4y722CBR+XSyGi/iGY9cs5GOWwkhtI7LV98/d6B+ N6P9V2HhAeRFWId1exLYlD03qwesXUSiMymObj0zsKhRotJ8dcUx66wJtOvrumZf lUf9FKXZF5b8cbUOAnSCcVZ/YdZcwwItWAD0ZT2sGD5ZttnC0sKnrFtEkbeMGGpN NG9v1lNYhqpmVE9jsSBXFSKVaDB1ipqqtxB0mSaK0/6aTOg8YMwKqxonuBra9sz3 SqXwP25Qk5++syB2vZVdJNFAl9gjlapYrtTAqdYdrTQCSkIHeyiEIl9IT4lMupWR JgdYo6OEjpob11GKYnNjixo0REwy2cDXSqWvauZEBbriQ2b0jbI= =YctX -----END PGP SIGNATURE----- --m3sipayj4evvlhxl--