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
/ 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
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
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.
: 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
?
- 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
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
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
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
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
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
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
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
13 matches
Mail list logo
