Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
I agree, regardless of libvirt's needs, p9fs needs to be secure for any non-root user using QEMU. As non-root I should be able todo $ qemu -virtfs $HOME/shared and have strong confidence that symlink attacks can't be used by the guest to access other locations nuder $HOME. A virtfs feature that needs root therefore needs to be in a separate process. Either QEMU needs to fork or virtfs could use a separate daemon binary. One other idea I just had is 'fakechroot'. This is basically an LD_PRELOAD hack which wraps the C library's native chroot(), open() etc call to do chroot in userspace, thus avoiding a need for root privileges. Either you could just invoke QEMU via fakechroot, enabling your code from these patches to be used as non-root. Or we could take the code from the fakechroot library and use that directly in the p9fs code to apply the path security checks With fakechroot is that I can still do following: chroot(/etc/cups); fd = open(../passwd, O_RDONLY); It does not check access beyond the chroot path. Also in virtio-9p case, a modified guest kernel can send a symbolic link and that could resolve outside chroot path. passthrough security model in virtio-9p needs root privilege not only for chroot() syscall but also to do chown and chmod on files created by the guest. So IMHO fakechroot can't be used in this case.
Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
On Tuesday, September 06, 2011 08:18:22 PM Stefan Hajnoczi wrote: A virtfs feature that needs root therefore needs to be in a separate process. Either QEMU needs to fork or virtfs could use a separate daemon binary. You have already implemented the fork approach in the chroot patches. Handle-based open could work in the same way. To summarize this architecture: all path-related operations are performed by a separate privileged process. File descriptors are passed to QEMU over a UNIX domain socket. This way QEMU can do the actual read(2)/write(2) calls directly to/from guest memory. I think it would be nice to build a completely separate binary that QEMU connects to. The separate binary would have a much smaller footprint (doesn't include QEMU code). More importantly the privileged/unprivileged boundary would be simple and could be automatically set up by libvirt: Hi Stefan, Thanks for your inputs. Sorry for the delayed reply. $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/ $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \ -device virtio-9p-pci,fsdev=my_fs We already isolated all path related operations in a privileged process. Should we add this complexity? If we take this approach, for handle based filesystem driver, we need to ship another binary. Won't it be an usability issue for people who use qemu directly?
Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
On Tue, Sep 06, 2011 at 03:48:22PM +0100, Stefan Hajnoczi wrote: On Mon, Sep 05, 2011 at 09:48:21PM +0530, M. Mohan Kumar wrote: Qemu need to be invoked by root user for using virtfs with passthrough security model (i.e to use chroot() syscall). Question is: Is running qemu by root user expected and allowed? Some of the virtfs features can be utilized only if qemu is started by root user (for example passthrough security model and handle based file driver need root privilege). This issue can be resolved by root user starting qemu and spawning a process with root privilege to do all privileged operations there and main qemu process dropping its privileges to avoid any security issue in running qemu in root mode. Privileged operations can be done similar to the chroot patchset. But how to determine to which user-id(ie non root user id) qemu needs to drop the privileges? Do we have a common user-id across all distributions/systems to which qemu process can be dropped down? Also it becomes too complex i.e when a new feature needing root privilege is added, a process with root privilege needs to be created to handle this. So is it allowed to run qemu by root user? If no, is it okay to add the complexity of adding a root privilege process for each feature that needs root privilege? I believe libvirt performs the privilege dropping itself and then invokes QEMU. So in the context of KVM + libvirt we do not have privileges in QEMU. Of course the administrator can edit /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. root). But the intention here is to run QEMU unprivileged. QEMU has its own -runas switch which may be used when QEMU is run directly by a user or by custom scripts. This switch looks up the user and switches to their uid/gid/groups. We need to think carefully before adding privileged features to QEMU since they usually require extra configuration to safely limit the group of users who may use the feature. These features will be unavailable to unprivileged users on a system. I agree, regardless of libvirt's needs, p9fs needs to be secure for any non-root user using QEMU. As non-root I should be able todo $ qemu -virtfs $HOME/shared and have strong confidence that symlink attacks can't be used by the guest to access other locations nuder $HOME. A virtfs feature that needs root therefore needs to be in a separate process. Either QEMU needs to fork or virtfs could use a separate daemon binary. One other idea I just had is 'fakechroot'. This is basically an LD_PRELOAD hack which wraps the C library's native chroot(), open() etc call to do chroot in userspace, thus avoiding a need for root privileges. Either you could just invoke QEMU via fakechroot, enabling your code from these patches to be used as non-root. Or we could take the code from the fakechroot library and use that directly in the p9fs code to apply the path security checks Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
On Mon, Sep 05, 2011 at 09:48:21PM +0530, M. Mohan Kumar wrote: Qemu need to be invoked by root user for using virtfs with passthrough security model (i.e to use chroot() syscall). Question is: Is running qemu by root user expected and allowed? Some of the virtfs features can be utilized only if qemu is started by root user (for example passthrough security model and handle based file driver need root privilege). This issue can be resolved by root user starting qemu and spawning a process with root privilege to do all privileged operations there and main qemu process dropping its privileges to avoid any security issue in running qemu in root mode. Privileged operations can be done similar to the chroot patchset. But how to determine to which user-id(ie non root user id) qemu needs to drop the privileges? Do we have a common user-id across all distributions/systems to which qemu process can be dropped down? Also it becomes too complex i.e when a new feature needing root privilege is added, a process with root privilege needs to be created to handle this. So is it allowed to run qemu by root user? If no, is it okay to add the complexity of adding a root privilege process for each feature that needs root privilege? I believe libvirt performs the privilege dropping itself and then invokes QEMU. So in the context of KVM + libvirt we do not have privileges in QEMU. Of course the administrator can edit /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. root). But the intention here is to run QEMU unprivileged. QEMU has its own -runas switch which may be used when QEMU is run directly by a user or by custom scripts. This switch looks up the user and switches to their uid/gid/groups. We need to think carefully before adding privileged features to QEMU since they usually require extra configuration to safely limit the group of users who may use the feature. These features will be unavailable to unprivileged users on a system. The main part of QEMU (vcpu execution and device emulation) should never run privileged. This way attacks on QEMU's code are limited to giving unprivileged access on the host. A virtfs feature that needs root therefore needs to be in a separate process. Either QEMU needs to fork or virtfs could use a separate daemon binary. You have already implemented the fork approach in the chroot patches. Handle-based open could work in the same way. To summarize this architecture: all path-related operations are performed by a separate privileged process. File descriptors are passed to QEMU over a UNIX domain socket. This way QEMU can do the actual read(2)/write(2) calls directly to/from guest memory. I think it would be nice to build a completely separate binary that QEMU connects to. The separate binary would have a much smaller footprint (doesn't include QEMU code). More importantly the privileged/unprivileged boundary would be simple and could be automatically set up by libvirt: $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/ $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \ -device virtio-9p-pci,fsdev=my_fs Stefan
Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
Sorry, I forgot to include Daniel Berrange who might have thoughts about a nice way of running the privileged virtfs helper and how to integrate with libvirt. On Tue, Sep 6, 2011 at 3:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Mon, Sep 05, 2011 at 09:48:21PM +0530, M. Mohan Kumar wrote: Qemu need to be invoked by root user for using virtfs with passthrough security model (i.e to use chroot() syscall). Question is: Is running qemu by root user expected and allowed? Some of the virtfs features can be utilized only if qemu is started by root user (for example passthrough security model and handle based file driver need root privilege). This issue can be resolved by root user starting qemu and spawning a process with root privilege to do all privileged operations there and main qemu process dropping its privileges to avoid any security issue in running qemu in root mode. Privileged operations can be done similar to the chroot patchset. But how to determine to which user-id(ie non root user id) qemu needs to drop the privileges? Do we have a common user-id across all distributions/systems to which qemu process can be dropped down? Also it becomes too complex i.e when a new feature needing root privilege is added, a process with root privilege needs to be created to handle this. So is it allowed to run qemu by root user? If no, is it okay to add the complexity of adding a root privilege process for each feature that needs root privilege? I believe libvirt performs the privilege dropping itself and then invokes QEMU. So in the context of KVM + libvirt we do not have privileges in QEMU. Of course the administrator can edit /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. root). But the intention here is to run QEMU unprivileged. QEMU has its own -runas switch which may be used when QEMU is run directly by a user or by custom scripts. This switch looks up the user and switches to their uid/gid/groups. We need to think carefully before adding privileged features to QEMU since they usually require extra configuration to safely limit the group of users who may use the feature. These features will be unavailable to unprivileged users on a system. The main part of QEMU (vcpu execution and device emulation) should never run privileged. This way attacks on QEMU's code are limited to giving unprivileged access on the host. A virtfs feature that needs root therefore needs to be in a separate process. Either QEMU needs to fork or virtfs could use a separate daemon binary. You have already implemented the fork approach in the chroot patches. Handle-based open could work in the same way. To summarize this architecture: all path-related operations are performed by a separate privileged process. File descriptors are passed to QEMU over a UNIX domain socket. This way QEMU can do the actual read(2)/write(2) calls directly to/from guest memory. I think it would be nice to build a completely separate binary that QEMU connects to. The separate binary would have a much smaller footprint (doesn't include QEMU code). More importantly the privileged/unprivileged boundary would be simple and could be automatically set up by libvirt: $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/ $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \ -device virtio-9p-pci,fsdev=my_fs Stefan
[Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model
In passthrough security model, following symbolic links in the server side could result in TOCTTOU vulnerabilities. (http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use) This patchset resolves this issue by creating a dedicated process which chroots into the share path and all file object access are done in the chroot environment. This patchset implements chroot environment, provides necessary functions that can be used by the passthrough function calls. Qemu need to be invoked by root user for using virtfs with passthrough security model (i.e to use chroot() syscall). Question is: Is running qemu by root user expected and allowed? Some of the virtfs features can be utilized only if qemu is started by root user (for example passthrough security model and handle based file driver need root privilege). This issue can be resolved by root user starting qemu and spawning a process with root privilege to do all privileged operations there and main qemu process dropping its privileges to avoid any security issue in running qemu in root mode. Privileged operations can be done similar to the chroot patchset. But how to determine to which user-id(ie non root user id) qemu needs to drop the privileges? Do we have a common user-id across all distributions/systems to which qemu process can be dropped down? Also it becomes too complex i.e when a new feature needing root privilege is added, a process with root privilege needs to be created to handle this. So is it allowed to run qemu by root user? If no, is it okay to add the complexity of adding a root privilege process for each feature that needs root privilege? Changes from version V11: * Rebased on top of latest qemu tree * Moved chroot process creation into local_init function * g_malloc/g_free instead qemu_malloc/g_free * Rename qemu_recv function to chroot_recv Changes from version V10: * Added support to do lstat and readlink from chroot process * Fixed an issue with dealing fds when qemu process reached maxfds limit Changes from version V9: * Error handling in special file object creation in virtio-9p-local.c Changes from version V8: * Make chmod and chown also operate under chroot process * Check for invalid path requests, minor cleanups Changes from version V7: * Add two chroot methods remove and rename * Minor cleanups like consolidating functions Changes from version V6: * Send only fd/errno in socket operations instead of FdInfo structure * Minor cleanups Changes from version V5: * Return errno on failure instead of setting errno * Minor cleanups like updated comments, enable CONFIG_THREAD if CONFIG_VIRTFS is enabled Changes from version V4: * Avoid using malloc/free inside chroot process * Seperate chroot server and client functions Changes from version V3 * Return EIO incase of socket read/write fail instead of exiting * Changed data types as suggested by Blue Swirl * Chroot process reports error through qemu process Changes from version V2 * Treat socket IO errors as fatal, ie qemu will exit * Split patchset based on chroot side (server) and qemu side(client) functionalities M. Mohan Kumar (15): Implement qemu_read_full virtio-9p: Enable CONFIG_THREAD if CONFIG_VIRTFS is enabled virtio-9p: Provide chroot worker side interfaces virtio-9p: qemu interfaces for chroot environment virtio-9p: Support for opening a file in chroot environment virtio-9p: Create support in chroot environment virtio-9p: Creating special files in chroot environment virtio-9p: Removing file or directory in chroot environment virtio-9p: Rename in chroot environment virtio-9p: Move file post creation changes to none security model virtio-9p: chmod in chroot environment virtio-9p: chown in chroot environment virtio-9p: stat in chroot environment virtio-9p: readlink in chroot environment virtio-9p: Chroot environment for other functions Makefile.objs |1 + configure |1 + fsdev/file-op-9p.h|3 + hw/9pfs/virtio-9p-chroot-worker.c | 413 + hw/9pfs/virtio-9p-chroot.c| 173 hw/9pfs/virtio-9p-chroot.h| 54 + hw/9pfs/virtio-9p-device.c|1 + hw/9pfs/virtio-9p-local.c | 277 - osdep.c | 32 +++ qemu-common.h |2 + 10 files changed, 907 insertions(+), 50 deletions(-) create mode 100644 hw/9pfs/virtio-9p-chroot-worker.c create mode 100644 hw/9pfs/virtio-9p-chroot.c create mode 100644 hw/9pfs/virtio-9p-chroot.h -- 1.7.5.4
