aboutsummaryrefslogtreecommitdiff
path: root/hw/9pfs/9p-util.h
AgeCommit message (Collapse)AuthorFilesLines
2024-12-109pfs: fix regression regarding CVE-2023-2861Christian Schoenebeck1-10/+17
The released fix for this CVE: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)") caused a regression with security_model=passthrough. When handling a 'Tmknod' request there was a side effect that 'Tmknod' request could fail as 9p server was trying to adjust permissions: #6 close_if_special_file (fd=30) at ../hw/9pfs/9p-util.h:140 #7 openat_file (mode=<optimized out>, flags=2228224, name=<optimized out>, dirfd=<optimized out>) at ../hw/9pfs/9p-util.h:181 #8 fchmodat_nofollow (dirfd=dirfd@entry=31, name=name@entry=0x5555577ea6e0 "mysocket", mode=493) at ../hw/9pfs/9p-local.c:360 #9 local_set_cred_passthrough (credp=0x7ffbbc4ace10, name=0x5555577ea6e0 "mysocket", dirfd=31, fs_ctx=0x55555811f528) at ../hw/9pfs/9p-local.c:457 #10 local_mknod (fs_ctx=0x55555811f528, dir_path=<optimized out>, name=0x5555577ea6e0 "mysocket", credp=0x7ffbbc4ace10) at ../hw/9pfs/9p-local.c:702 #11 v9fs_co_mknod (pdu=pdu@entry=0x555558121140, fidp=fidp@entry=0x5555574c46c0, name=name@entry=0x7ffbbc4aced0, uid=1000, gid=1000, dev=<optimized out>, mode=49645, stbuf=0x7ffbbc4acef0) at ../hw/9pfs/cofs.c:205 #12 v9fs_mknod (opaque=0x555558121140) at ../hw/9pfs/9p.c:3711 That's because server was opening the special file to adjust permissions, however it was using O_PATH and it would have not returned the file descriptor to guest. So the call to close_if_special_file() on that branch was incorrect. Let's lift the restriction introduced by f6b0de53fb8 such that it would allow to open special files on host if O_PATH flag is supplied, not only for 9p server's own operations as described above, but also for any client 'Topen' request. It is safe to allow opening special files with O_PATH on host, because O_PATH only allows path based operations on the resulting file descriptor and prevents I/O such as read() and write() on that file descriptor. Fixes: f6b0de53fb8 ("9pfs: prevent opening special files (CVE-2023-2861)") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2337 Reported-by: Dirk Herrendorfer <d.herrendoerfer@de.ibm.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Tested-by: Dirk Herrendorfer <d.herrendoerfer@de.ibm.com> Message-Id: <E1tJWbk-007BH4-OB@kylie.crudebyte.com>
2023-07-25hw/9pfs: spelling fixesMichael Tokarev1-1/+1
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2023-06-089pfs: prevent opening special files (CVE-2023-2861)Christian Schoenebeck1-0/+39
The 9p protocol does not specifically define how server shall behave when client tries to open a special file, however from security POV it does make sense for 9p server to prohibit opening any special file on host side in general. A sane Linux 9p client for instance would never attempt to open a special file on host side, it would always handle those exclusively on its guest side. A malicious client however could potentially escape from the exported 9p tree by creating and opening a device file on host side. With QEMU this could only be exploited in the following unsafe setups: - Running QEMU binary as root AND 9p 'local' fs driver AND 'passthrough' security model. or - Using 9p 'proxy' fs driver (which is running its helper daemon as root). These setups were already discouraged for safety reasons before, however for obvious reasons we are now tightening behaviour on this. Fixes: CVE-2023-2861 Reported-by: Yanwu Shen <ywsPlz@gmail.com> Reported-by: Jietao Xiao <shawtao1125@gmail.com> Reported-by: Jinku Li <jkli@xidian.edu.cn> Reported-by: Wenbo Shen <shenwenbo@zju.edu.cn> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-Id: <E1q6w7r-0000Q0-NM@lizzy.crudebyte.com>
2022-12-23hw/9pfs: Replace the direct call to xxxat() APIs with a wrapperBin Meng1-4/+11
xxxat() APIs are only available on POSIX platforms. For future extension to Windows, let's replace the direct call to xxxat() APIs with a wrapper. Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <20221219102022.2167736-4-bin.meng@windriver.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2022-12-23hw/9pfs: Drop unnecessary *xattr wrapper API declarationsBin Meng1-11/+0
These are not used anywhere in the source tree. Drop them. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <20221219102022.2167736-3-bin.meng@windriver.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2022-05-019pfs: fix wrong errno being sent to Linux client on macOS hostChristian Schoenebeck1-0/+30
Linux and macOS only share some errno definitions with equal macro name and value. In fact most mappings for errno are completely different on the two systems. This patch converts some important errno values from macOS host to corresponding Linux errno values before eventually sending such error codes along with 'Rlerror' replies (if 9p2000.L is used that is). Not having translated errnos before violated the 9p2000.L protocol spec, which says: " size[4] Rlerror tag[2] ecode[4] ... ecode is a numerical Linux errno. " https://github.com/chaos/diod/wiki/protocol#lerror----return-error-code This patch fixes a bunch of misbehaviours when running a Linux client on macOS host. For instance this patch fixes: mount -t 9p -o posixacl ... on Linux guest if security_mode=mapped was used for 9p server, which refused to mount successfully, because macOS returned ENOATTR==93 when client tried to retrieve POSIX ACL xattrs, because errno 93 is defined as EPROTONOSUPPORT==93 on Linux, so Linux client believed that xattrs were not supported by filesystem on host in general. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Link: https://lore.kernel.org/qemu-devel/20220421124835.3e664669@bahia/ Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <b322ab298a62069e527d2b032028bdc9115afacd.1651228001.git.qemu_oss@crudebyte.com>
2022-05-019pfs: fix wrong encoding of rdev field in Rgetattr on macOSChristian Schoenebeck1-0/+39
The 'rdev' field in 9p reponse 'Rgetattr' is of type dev_t, which is actually a system dependant type and therefore both the size and encoding of dev_t differ between macOS and Linux. So far we have sent 'rdev' to guest in host's dev_t format as-is, which caused devices to appear with wrong device numbers on guests running on macOS hosts, eventually leading to various misbehaviours on guest in conjunction with device files. This patch fixes this issue by converting the device number from host's dev_t format to Linux dev_t format. As 9p request 'Tgettattr' is exclusive to protocol version 9p2000.L, it should be fair to assume that 'rdev' field is assumed to be in Linux dev_t format by client as well. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Link: https://lore.kernel.org/qemu-devel/20220421093056.5ab1e7ed@bahia/ Reviewed-by: Greg Kurz <groug@kaod.org> Reviewed-by: Akihiko Odaki <akihiko.odaki@gmail.com> Message-Id: <b3a430c2c382ba69a7405e04c0b090ab0d86f17e.1651228001.git.qemu_oss@crudebyte.com>
2022-03-079pfs/9p-util.h: convert Doxygen -> kerneldoc formatChristian Schoenebeck1-5/+5
API doc comments in QEMU are supposed to be in kerneldoc format, so convert API doc comments from Doxygen format to kerneldoc format. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <dc1c4a85e233f5884ee5f6ec96b87db286083df7.1646314856.git.qemu_oss@crudebyte.com>
2022-03-079pfs: drop Doxygen format from qemu_dirent_dup() API commentChristian Schoenebeck1-2/+2
API doc comments in QEMU are supposed to be in kerneldoc format, so drop occurrences of "@c" which is Doxygen format for fixed-width text. Link: https://lore.kernel.org/qemu-devel/CAFEAcA89+ENOM6x19OEF53Kd2DWkhN5SN21Va0D7yepJSa3Jyg@mail.gmail.com/ Based-on: <E1nP9Oz-00043L-KJ@lizzy.crudebyte.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <E1nPTwO-0006pl-Np@lizzy.crudebyte.com>
2022-03-079pfs: move qemu_dirent_dup() from osdep -> 9p-utilChristian Schoenebeck1-0/+30
Function qemu_dirent_dup() is currently only used by 9pfs server, so move it from project global header osdep.h to 9pfs specific header 9p-util.h. Link: https://lore.kernel.org/qemu-devel/CAFEAcA_=HAUNomKD2wurSVaAHa5mrk22A1oHKLWUDjk7v6Khmg@mail.gmail.com/ Based-on: <20220227223522.91937-12-wwcohen@gmail.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <E1nP9Oz-00043L-KJ@lizzy.crudebyte.com>
2022-03-079p: darwin: Implement compatibility for mknodatKeno Fischer1-0/+11
Darwin does not support mknodat. However, to avoid race conditions with later setting the permissions, we must avoid using mknod on the full path instead. We could try to fchdir, but that would cause problems if multiple threads try to call mknodat at the same time. However, luckily there is a solution: Darwin includes a function that sets the cwd for the current thread only. This should suffice to use mknod safely. This function (pthread_fchdir_np) is protected by a check in meson in a patch later in this series. Signed-off-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> [Will Cohen: - Adjust coding style - Replace clang references with gcc - Note radar filed with Apple for missing syscall - Replace direct syscall with pthread_fchdir_np and adjust patch notes accordingly - Declare pthread_fchdir_np with - __attribute__((weak_import)) to allow checking for its presence before usage - Move declarations above cplusplus guard - Add CONFIG_PTHREAD_FCHDIR_NP to meson and check for presence in 9p-util - Rebase to apply cleanly on top of the 2022-02-10 changes to 9pfs - Fix line over 90 characters formatting error] Signed-off-by: Will Cohen <wwcohen@gmail.com> Message-Id: <20220227223522.91937-10-wwcohen@gmail.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2022-03-079p: darwin: Compatibility for f/l*xattrKeno Fischer1-0/+17
On darwin `fgetxattr` takes two extra optional arguments, and the l* variants are not defined (in favor of an extra flag to the regular variants. Signed-off-by: Keno Fischer <keno@juliacomputing.com> [Michael Roitzsch: - Rebase for NixOS] Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> Signed-off-by: Will Cohen <wwcohen@gmail.com> Message-Id: <20220227223522.91937-9-wwcohen@gmail.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2022-03-079p: darwin: Ignore O_{NOATIME, DIRECT}Keno Fischer1-0/+4
Darwin doesn't have either of these flags. Darwin does have F_NOCACHE, which is similar to O_DIRECT, but has different enough semantics that other projects don't generally map them automatically. In any case, we don't support O_DIRECT on Linux at the moment either. Signed-off-by: Keno Fischer <keno@juliacomputing.com> [Michael Roitzsch: - Rebase for NixOS] Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> [Will Cohen: - Adjust coding style] Signed-off-by: Will Cohen <wwcohen@gmail.com> Message-Id: <20220227223522.91937-6-wwcohen@gmail.com> [C.S.: - Fix compiler warning "unused label 'again'". ] Link: https://lore.kernel.org/qemu-devel/11201492.CjeqJxXfGd@silver/ Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2022-03-079p: darwin: Handle struct dirent differencesKeno Fischer1-0/+16
On darwin d_seekoff exists, but is optional and does not seem to be commonly used by file systems. Use `telldir` instead to obtain the seek offset and inject it into d_seekoff, and create a qemu_dirent_off helper to call it appropriately when appropriate. Signed-off-by: Keno Fischer <keno@juliacomputing.com> [Michael Roitzsch: - Rebase for NixOS] Signed-off-by: Michael Roitzsch <reactorcontrol@icloud.com> [Will Cohen: - Adjust to pass testing - Ensure that d_seekoff is filled using telldir on darwin, and create qemu_dirent_off helper to decide which to access] [Fabian Franz: - Add telldir error handling for darwin] Signed-off-by: Fabian Franz <fabianfranz.oss@gmail.com> [Will Cohen: - Ensure that telldir error handling uses signed int - Cleanup of telldir error handling - Remove superfluous error handling for qemu_dirent_off - Adjust formatting - Use qemu_dirent_off in codir.c - Declare qemu_dirent_off as static to prevent linker error - Move qemu_dirent_off above the end-of-file endif to fix compilation] Signed-off-by: Will Cohen <wwcohen@gmail.com> Message-Id: <20220227223522.91937-5-wwcohen@gmail.com> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
2020-05-149pfs: local: ignore O_NOATIME if we don't have permissionsOmar Sandoval1-0/+13
QEMU's local 9pfs server passes through O_NOATIME from the client. If the QEMU process doesn't have permissions to use O_NOATIME (namely, it does not own the file nor have the CAP_FOWNER capability), the open will fail. This causes issues when from the client's point of view, it believes it has permissions to use O_NOATIME (e.g., a process running as root in the virtual machine). Additionally, overlayfs on Linux opens files on the lower layer using O_NOATIME, so in this case a 9pfs mount can't be used as a lower layer for overlayfs (cf. https://github.com/osandov/drgn/blob/dabfe1971951701da13863dbe6d8a1d172ad9650/vmtest/onoatimehack.c and https://github.com/NixOS/nixpkgs/issues/54509). Luckily, O_NOATIME is effectively a hint, and is often ignored by, e.g., network filesystems. open(2) notes that O_NOATIME "may not be effective on all filesystems. One example is NFS, where the server maintains the access time." This means that we can honor it when possible but fall back to ignoring it. Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Message-Id: <e9bee604e8df528584693a4ec474ded6295ce8ad.1587149256.git.osandov@fb.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2018-06-079p: Move a couple xattr functions to 9p-utilKeno Fischer1-0/+4
These functions will need custom implementations on Darwin. Since the implementation is very similar among all of them, and 9p-util already has the _nofollow version of fgetxattrat, let's move them all there. Signed-off-by: Keno Fischer <keno@juliacomputing.com> Signed-off-by: Greg Kurz <groug@kaod.org>
2017-08-109pfs: local: fix fchmodat_nofollow() limitationsGreg Kurz1-9/+15
This function has to ensure it doesn't follow a symlink that could be used to escape the virtfs directory. This could be easily achieved if fchmodat() on linux honored the AT_SYMLINK_NOFOLLOW flag as described in POSIX, but it doesn't. There was a tentative to implement a new fchmodat2() syscall with the correct semantics: https://patchwork.kernel.org/patch/9596301/ but it didn't gain much momentum. Also it was suggested to look at an O_PATH based solution in the first place. The current implementation covers most use-cases, but it notably fails if: - the target path has access rights equal to 0000 (openat() returns EPERM), => once you've done chmod(0000) on a file, you can never chmod() again - the target path is UNIX domain socket (openat() returns ENXIO) => bind() of UNIX domain sockets fails if the file is on 9pfs The solution is to use O_PATH: openat() now succeeds in both cases, and we can ensure the path isn't a symlink with fstat(). The associated entry in "/proc/self/fd" can hence be safely passed to the regular chmod() syscall. The previous behavior is kept for older systems that don't have O_PATH. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> Tested-by: Zhi Yong Wu <zhiyong.wu@ucloud.cn> Acked-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-05-259pfs: local: simplify file openingGreg Kurz1-2/+0
The logic to open a path currently sits between local_open_nofollow() and the relative_openat_nofollow() helper, which has no other user. For the sake of clarity, this patch moves all the code of the helper into its unique caller. While here we also: - drop the code to skip leading "/" because the backend isn't supposed to pass anything but relative paths without consecutive slashes. The assert() is kept because we really don't want a buggy backend to pass an absolute path to openat(). - use strchrnul() to get a simpler code. This is ok since virtfs is for linux+glibc hosts only. - don't dup() the initial directory and add an assert() to ensure we don't return the global mountfd to the caller. BTW, this would mean that the caller passed an empty path, which isn't supposed to happen either. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> [groug: fixed typos in changelog]
2017-03-069pfs: fix vulnerability in openat_dir() and local_unlinkat_common()Greg Kurz1-1/+2
We should pass O_NOFOLLOW otherwise openat() will follow symlinks and make QEMU vulnerable. While here, we also fix local_unlinkat_common() to use openat_dir() for the same reasons (it was a leftover in the original patchset actually). This fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2017-03-069pfs: fix O_PATH build break with older glibc versionsGreg Kurz1-1/+6
When O_PATH is used with O_DIRECTORY, it only acts as an optimization: the openat() syscall simply finds the name in the VFS, and doesn't trigger the underlying filesystem. On systems that don't define O_PATH, because they have glibc version 2.13 or older for example, we can safely omit it. We don't want to deactivate O_PATH globally though, in case it is used without O_DIRECTORY. The is done with a dedicated macro. Systems without O_PATH may thus fail to resolve names that involve unreadable directories, compared to newer systems succeeding, but such corner case failure is our only option on those older systems to avoid the security hole of chasing symlinks inappropriately. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Eric Blake <eblake@redhat.com> (added last paragraph to changelog as suggested by Eric Blake) Signed-off-by: Greg Kurz <groug@kaod.org>
2017-02-289pfs: local: lsetxattr: don't follow symlinksGreg Kurz1-0/+2
The local_lsetxattr() callback is vulnerable to symlink attacks because it calls lsetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fsetxattrat() function: it is implemented with /proc/self/fd which provides a trusted path that can be safely passed to lsetxattr(). local_lsetxattr() is converted to use this helper and opendir_nofollow(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: local: lgetxattr: don't follow symlinksGreg Kurz1-0/+2
The local_lgetxattr() callback is vulnerable to symlink attacks because it calls lgetxattr() which follows symbolic links in all path elements but the rightmost one. This patch introduces a helper to emulate the non-existing fgetxattrat() function: it is implemented with /proc/self/fd which provides a trusted path that can be safely passed to lgetxattr(). local_lgetxattr() is converted to use this helper and opendir_nofollow(). This partly fixes CVE-2016-9602. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-02-289pfs: introduce relative_openat_nofollow() helperGreg Kurz1-0/+50
When using the passthrough security mode, symbolic links created by the guest are actual symbolic links on the host file system. Since the resolution of symbolic links during path walk is supposed to occur on the client side. The server should hence never receive any path pointing to an actual symbolic link. This isn't guaranteed by the protocol though, and malicious code in the guest can trick the server to issue various syscalls on paths whose one or more elements are symbolic links. In the case of the "local" backend using the "passthrough" or "none" security modes, the guest can directly create symbolic links to arbitrary locations on the host (as per spec). The "mapped-xattr" and "mapped-file" security modes are also affected to a lesser extent as they require some help from an external entity to create actual symbolic links on the host, i.e. another guest using "passthrough" mode for example. The current code hence relies on O_NOFOLLOW and "l*()" variants of system calls. Unfortunately, this only applies to the rightmost path component. A guest could maliciously replace any component in a trusted path with a symbolic link. This could allow any guest to escape a virtfs shared folder. This patch introduces a variant of the openat() syscall that successively opens each path element with O_NOFOLLOW. When passing a file descriptor pointing to a trusted directory, one is guaranteed to be returned a file descriptor pointing to a path which is beneath the trusted directory. This will be used by subsequent patches to implement symlink-safe path walk for any access to the backend. Symbolic links aren't the only threats actually: a malicious guest could change a path element to point to other types of file with undesirable effects: - a named pipe or any other thing that would cause openat() to block - a terminal device which would become QEMU's controlling terminal These issues can be addressed with O_NONBLOCK and O_NOCTTY. Two helpers are introduced: one to open intermediate path elements and one to open the rightmost path element. Suggested-by: Jann Horn <jannh@google.com> Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> (renamed openat_nofollow() to relative_openat_nofollow(), assert path is relative and doesn't contain '//', fixed side-effect in assert, Greg Kurz) Signed-off-by: Greg Kurz <groug@kaod.org>
generated by cgit v1.1 at 2024-12-26 21:36:13 +0000