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
