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 r
> > 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 a
> 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 implementa
> A document is already describing something similar.
> http://docs.ganeti.org/ganeti/2.13/html/design-kvmd.html
I always tried to avoid that.
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
On Mon, 27 Jul 2015 20:11:54 +0200 (CEST)
Wolfgang Bumiller 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 d
> 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
> 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
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
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 experimen
ic Blevins"
Cc: "pve-devel"
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"
Cc: "pve-devel"
Can qemu create the tap interface without root privilege ?
- Mail original -
De: "Eric Blevins"
Cc: "pve-devel"
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
io).
>
> Not sure about disks with /dev/ mapping ?
>
>
>
> - Mail original -
> De: "Wolfgang Bumiller"
> À: "Eric Blevins"
> Cc: "pve-devel"
> Envoyé: Lundi 27 Juillet 2015 15:53:00
> Objet: Re: [pve-devel] Running KVM as root is a security iss
On Mon, Jul 27, 2015 at 04:07:10PM +0200, Alexandre DERUMIER 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 passthrou
vfio).
Not sure about disks with /dev/ mapping ?
- Mail original -
De: "Wolfgang Bumiller"
À: "Eric Blevins"
Cc: "pve-devel"
Envoyé: Lundi 27 Juillet 2015 15:53:00
Objet: Re: [pve-devel] Running KVM as root is a security issue
> A patch exists to preven
> 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
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
16 matches
Mail list logo