Re: [pve-devel] Running KVM as root is a security issue
A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Included in the current 2.4 devel build. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. Ideally the VM can be started directly as a user, though, rather than using the -runas switch. That will be some work though. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. I think that pci passthrough need root access too. (maybe not with vfio). Not sure about disks with /dev/ mapping ? - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: Eric Blevins ericlb...@gmail.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Lundi 27 Juillet 2015 15:53:00 Objet: Re: [pve-devel] Running KVM as root is a security issue A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Included in the current 2.4 devel build. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. Ideally the VM can be started directly as a user, though, rather than using the -runas switch. That will be some work though. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
[pve-devel] Running KVM as root is a security issue
I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox. But when I see exploits like that the first thought in my mind is how easy it would be for such an exploit to get root on the Proxmox host. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. However when I try to open a console the KVM process fails. I suspect this is just some permissions in creating the socket but not investidated. A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Any chance this security issue can be fixed before the 4.0 release? Eric ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
Le 27/07/2015 15:29, Eric Blevins a écrit : I have no idea if CVE-2015-5154 that Stephan inquired about affests Proxmox. But when I see exploits like that the first thought in my mind is how easy it would be for such an exploit to get root on the Proxmox host. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. However when I try to open a console the KVM process fails. I suspect this is just some permissions in creating the socket but not investidated. A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Any chance this security issue can be fixed before the 4.0 release? Eric Hi, Maybe it could even go further, allowing to separate some VMs using different usernames to isolate them somehow? Cheers Gilles ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
we could create the tap interface, tunctl -t tap0 -u myuser then pass it to qemu without script -netdev tap,ifname=tap0,id=mynet0,script=no (and the bridge create, tap plug, could be also done manually in qemuserver vmstart) - Mail original - De: aderumier aderum...@odiso.com À: Eric Blevins ericlb...@gmail.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Lundi 27 Juillet 2015 18:06:06 Objet: Re: [pve-devel] Running KVM as root is a security issue Can qemu create the tap interface without root privilege ? - Mail original - De: Eric Blevins ericlb...@gmail.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Lundi 27 Juillet 2015 16:33:49 Objet: Re: [pve-devel] Running KVM as root is a security issue Having only PCI passthrough VMs running as root would be a huge improvement. Maybe cgroups could be used to reduce the risk. Exit scripts could be suid if needed. An exploted VM could potentially use the suid pve-bridgedown script to destroy bridges of other VMs. Long term I think a better idea is needed. The exit scripts could simply notify some other privlidged process that they are shutting down. Privlidged process would then verify that VM is down and do whatever cleanup is necessary. On Mon, Jul 27, 2015 at 10:07 AM, Alexandre DERUMIER aderum...@odiso.com wrote: Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. I think that pci passthrough need root access too. (maybe not with vfio). Not sure about disks with /dev/ mapping ? - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: Eric Blevins ericlb...@gmail.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Lundi 27 Juillet 2015 15:53:00 Objet: Re: [pve-devel] Running KVM as root is a security issue A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Included in the current 2.4 devel build. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. Ideally the VM can be started directly as a user, though, rather than using the -runas switch. That will be some work though. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
Having only PCI passthrough VMs running as root would be a huge improvement. Maybe cgroups could be used to reduce the risk. Exit scripts could be suid if needed. An exploted VM could potentially use the suid pve-bridgedown script to destroy bridges of other VMs. Long term I think a better idea is needed. The exit scripts could simply notify some other privlidged process that they are shutting down. Privlidged process would then verify that VM is down and do whatever cleanup is necessary. On Mon, Jul 27, 2015 at 10:07 AM, Alexandre DERUMIER aderum...@odiso.com wrote: Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. I think that pci passthrough need root access too. (maybe not with vfio). Not sure about disks with /dev/ mapping ? - Mail original - De: Wolfgang Bumiller w.bumil...@proxmox.com À: Eric Blevins ericlb...@gmail.com Cc: pve-devel pve-devel@pve.proxmox.com Envoyé: Lundi 27 Juillet 2015 15:53:00 Objet: Re: [pve-devel] Running KVM as root is a security issue A patch exists to prevent a crash when a socket cannot be opened. https://lists.gnu.org/archive/html/qemu-devel/2015-05/msg00577.html Included in the current 2.4 devel build. I've done some experimenting. If I take the KVM command as generated by Proxmox and simply add -runas nobody the VM starts up and runs without a problem. Yes, that much I've tested, too. I'm worried about the shutdown scripts though (bridgedown). They might lack permissions if qemu doesn't keep a privileged parent process around for those. Ideally the VM can be started directly as a user, though, rather than using the -runas switch. That will be some work though. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
Exit scripts could be suid if needed. Scripts cannot be suid, because the executable is their interpreter, iow /bin/sh, which in turn is not setuid-root. The exit scripts could simply notify some other privlidged process that they are shutting down. This is better. Even better would be a monitoring process that doesn't need to be signaled. (Coincidentally, this would also add the possibility of adding reliably-fired exit-time hooks.) Can qemu create the tap interface without root privilege ? (...) tunctl -t tap0 -u myuser Create - no, but they can be assigned a user. The iproute2 version of the above command would be: $ ip tuntap add tap0 mode tap user myuser You can even mknod them into a node-file (which is how they work on BSDs.) Also, qemu has a helper-script parameter which can be used to have them created. This would have to be a compiled program and doesn't even need to be suid-root - all it needs is CAP_NET_ADMIN. There are a few ioctls that the user cannot issue to tap devices, though, I'm not sure qemu needs those. (socat for instance fails on taps as a user). But this can be easily patched if necessary. Personally I'd like to generally aim for a whitelist permission model. I.o.w.: never actually use root or setuid-root executables, but provide the necessary POSIX capabilities, apparmor permissions and filesystem access. But I fear it's a long and rocky road to get there. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
I guess it would also help if we add a reasonable apparmor profile? ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
I guess it would also help if we add a reasonable apparmor profile? apparmor profiles would be greatly appreciated ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
A monitoring process which does not rely on events could potentially be a resource hawk. Well I wasn't suggesting a busy-waiting daemon. More like listening with inotify on the qemu cgroup directory, since we use systemd-run to run VMs in a scope now, this would allow an event-based implementation. 1) We know when a new VM starts. 2) When a VM a QMP socket is created like /var/run/qemu-server/nnn.qmp 3) The QMP socket is bidirectional so it should be possible to listen to events. A document is already describing something similar. http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html Yes, a design like this would be a possibility. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
On Mon, 27 Jul 2015 20:11:54 +0200 (CEST) Wolfgang Bumiller w.bumil...@proxmox.com wrote: This is better. Even better would be a monitoring process that doesn't need to be signaled. (Coincidentally, this would also add the possibility of adding reliably-fired exit-time hooks.) A monitoring process which does not rely on events could potentially be a resource hawk. 1) We know when a new VM starts. 2) When a VM a QMP socket is created like /var/run/qemu-server/nnn.qmp 3) The QMP socket is bidirectional so it should be possible to listen to events. A document is already describing something similar. http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html Whether it is implemented or not, I do not know. -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xE3E80917 -- /usr/games/fortune -es says: Women aren't as mere as they used to be. -- Pogo pgpZkAKmO_2Mf.pgp Description: OpenPGP digital signature ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
A document is already describing something similar. http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html I always tried to avoid that. We can still use a shutdown script, but it needs to be something that can be compiled in order to get the necessary capabilities. Hmm, what's actually the current behavior regarding network interfaces when a kvm process is SIGKILLed? Also... tap devices can be made non-persistent. I wonder if there's a nice way to hand over a non-persistent tap device to qemu. It would then automatically be removed when the process shuts down. ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Re: [pve-devel] Running KVM as root is a security issue
I think the best option is to run every KVM as another user and chown the /var/lib/vz/images/VMID/ directory to that user. There will be vulnerabilities at any time and the best option is to just use other users to prevent execution of code on the host or modify other vms(read data). Best regards Henry Spanka -- Fügen Sie uns in die Liste vertrauenswürdiger Absender hinzu. If you have any further questions, please let us know. Mit freundlichen Grüßen / With best regards myVirtualserver.de | Development Team Henry Spanka ___ pve-devel mailing list pve-devel@pve.proxmox.com http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
