From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36410) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjqL4-00089d-CB for qemu-devel@nongnu.org; Fri, 03 Mar 2017 11:45:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjqKz-0008Ax-PD for qemu-devel@nongnu.org; Fri, 03 Mar 2017 11:45:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48344) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cjqKz-0008A5-FQ for qemu-devel@nongnu.org; Fri, 03 Mar 2017 11:45:49 -0500 References: <8FB6923C-8F97-497C-95DC-6F2D937725BC@gmail.com> <20170303164426.42472535@bahia.lan> <20170303162128.GD13631@redhat.com> From: Eric Blake Message-ID: Date: Fri, 3 Mar 2017 10:45:46 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="46HWIu5Qrd7U542MwKQieLh7r2iucfADH" Subject: Re: [Qemu-devel] git master build failure in 9pfs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , G 3 Cc: Mark Cave-Ayland , Greg Kurz , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --46HWIu5Qrd7U542MwKQieLh7r2iucfADH From: Eric Blake To: "Daniel P. Berrange" , G 3 Cc: Mark Cave-Ayland , Greg Kurz , qemu-devel qemu-devel Message-ID: Subject: Re: [Qemu-devel] git master build failure in 9pfs References: <8FB6923C-8F97-497C-95DC-6F2D937725BC@gmail.com> <20170303164426.42472535@bahia.lan> <20170303162128.GD13631@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/03/2017 10:40 AM, Eric Blake wrote: >> Isn't the use of O_PATH required in order to fix the recent >> security vulnerability in 9p ? If so, then defining it to >> 0 means the QEMU is silently becoming vulnerable once again >> which I don't think is a good idea. >=20 > My understanding is that O_PATH is an optimization. It lets openat() > succeed in some places where it would ordinarily fail (for example, it > can be used to open a dir with mode 0000) - the resulting fd is > limited-use (it cannot be used to read() or write(), but CAN be used as= > the relative fd for a subsequent openat(), for example). If you define= > O_PATH to 0, then attempts to traverse paths will fail where the could > have otherwise succeeded, but failure is okay (the CVE was that we were= > succeeding at opening through a guest-controlled symlink; whether we no= w > fail or guarantee that we are not going through a symlink is a quality > of implementation, but either way, we are at least immune from > succeeding through a symlink). [I hit send too soon] To put it in perspective, the 9p fixes included code for chmod() that falls back to fchmodat() - but Linux' fchmodat() is broken (it is not POSIX-compliant in that there is no race-free way to use AT_SYMLINK_NOFOLLOW, at least not until Greg gets his kernel patches approved that implement the fchmodat2() syscall [1]). The symptoms are that we now have cases where the guest will get failures where they could have otherwise succeeded if fchmodat() were not broken, but such cases are limited to corners where permissions are overly-tight; in the common case, the permissions will allow opening the file with O_RDONLY or O_WRONLY and fchmod() can be used. So a limited-use fix for the CVE that safely succeeds without symlinks in the common case but fails in the corner case of tight permissions (which is what defining O_PATH to 0 would do) is better than the pre-CVE state of code that succeeds but risks going through a user-controlled symlink. [1] https://lkml.org/lkml/2017/2/28/461 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --46HWIu5Qrd7U542MwKQieLh7r2iucfADH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJYuZ26AAoJEKeha0olJ0NqPb0IAKnzHsMM9nMQh1V2WLsLW6/d buXhQWB/kifD7nF8iXcPt5A/fIqGVG86eLzMK03qCIG0nQnyRLvoiQtSBrdHaE2t PpLRGH7ioHhWSJuDn2uP7kFgGHV3v+58Ntsu4TfyI3H2hzuyp80mkRGTDsIBCbvJ tUYp7nSGgNHVao8HqAGEC9dRK6gNm8mEhRqsPTqjJ7nu7JR1Vsn5pnTLl3bGoKyu M0QVoUKHwFebRU0bjezE6I8c5MEm5krzl19p86RIeuk4ypWo74aS8+XzePw+aWtS 8/X72CIBqYOOvev0Y4U9PhBt+cxtnk0tv1DT9m0gTsaqObGgZVPAug597IVogww= =AyBU -----END PGP SIGNATURE----- --46HWIu5Qrd7U542MwKQieLh7r2iucfADH--