Re: [Qemu-devel] git master build failure in 9pfs

[Eric Blake]

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.
> 
> 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 now
> 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

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature