On 12/08/2010 02:02 PM, Richard W.M. Jones wrote: > On Wed, Dec 08, 2010 at 04:50:11PM -0500, seth vidal wrote: >> On Wed, 2010-12-08 at 22:40 +0100, Till Maas wrote: >>> On Wed, Dec 08, 2010 at 09:00:51PM +0000, Richard W.M. Jones wrote: >>> >>>> To the original poster: even a VM isn't a completely robust way of >>>> preventing root escalations. If the developers are all in your >>>> "organization", how about using a cluestick-based method to prevent >>>> them doing this? >>> >>> I guess giving someone a shell account in a VM is usually not less safe >>> than giving someone shell access on the host of the VM, as long as the >>> VM does not use kvm and does not run as root. Because even if the user >>> could break out of the VM, he still has only the same privileges as when >>> he got a shell access to the host directly. >>> >> >> the point is to make the vm's be entirely disposable. >> >> >> So you make the vm >> build the pkg in mock >> suck the results off >> destroy the vm >> >> nothing to risk, then. > > If we're being picky then the hypervisor might be exploited during the > package build, with the exploit escalating to root on the host. It's > very hard to pull this off, but with security never say 'never'. > > In any case, using sVirt (libvirt + SELinux) should help. > > Rich. > Meh, take it one step further, do bare hardware kickstarts, then fire up the vm within... Or maybe flash the bios first, then do the kickstart then... :) -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
