On Wed, 2010-12-08 at 22:02 +0000, 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. > and this is where I stop caring. putting it in a vm means I don't care about it for MY systems b/c the systems are thrown away at the end of us. How the vendor/serviceprovider/etc of the vm-hosting-infrastructure protects themselves falls into the SEP category. -sv -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
