----- Original Message -----
> Having more things installed on the host means a larger attack
> surface.
Not if the host is properly locked down. And given that guests typically have more open services, and therefore a larger remote attack surface, the more there is in the guest, the less secure you are. You can do an Everything install in the host which gives a huge local attach surface, but if there is no entrance vector and you don't enable network services, it's no less secure than the guest and is probably far more secure. Your argument is silly given typical host/guest roles where the guest has a far large remote attack surface regardless of the host's local attack surface and is likely to be the remote entry point to get to the host. In that situation, minimizing the local attack surface of the guest (on the assumption that the remote compromise is going to happen in the guest and from there local attacks will be made either against the guest or the host) is far higher priority than the host.
> It's going to go away *in Fedora* much sooner than the timeframe it
> takes
> for old OSes to bitrot into the void, yes. You've totally ignored the
> point,
> which is that you won't be able to run it on the host when it isn't
> there.
No, he's well aware of that, which is why he *wants* it there.
Situation 1: run grub inside the guest from inside the guest vm, secure as you can't access anything but your virtual drive, so even a compromised grub can't effect the host unless the vm subsystem of the host is broken and allows access outside the scope of the virtual drive, but has the drawback that you actually have to boot up the guest instance in order to run grub, and that may not be possible if the guest's virtual block device has already undergone a resize. This is roughly equivalent to running any command in a chroot from within the chroot environment.
Situation 2: run grub off of the guest vm's block device, but run from the host context. This opens the host to the possibility of a chained compromise where the attacker first compromises the guest, then uses a compromised grub to compromise the host. The fact that the host's native block devices, in addition to just the virtual block devices that the guest vm would normally see, are present is the source of this security risk. This is roughly the same as running a program from a chroot environment outside of the chroot environment. It does, however, eliminate the conundrum from situation 1 where you might not be able to boot due to an already completed fs resize. This situation does not need to boot and can effectively deal with the resize. In the chroot analogy though, this is the most insecure thing to do of all.
Situation 3: run grub off of the host acting on the guest vm's block device and using the guest vm's boot loader files. This does not open up the host because the grub is from the host and can only be trojaned if the host has already been compromised. At no point does grub execute the boot loader files from the guest, it merely installs them. Worst case scenario is that a compromised guest stays compromised barring the possibility that an attacker can craft a special grub boot loader stage that causes the host grub binary to freak out (highly unlikely, but I would have to audit the code before I declared it impossible). This is equivalent to running a non-chroot based app upon the chroot environment, and in the chroot analogy this is generally considered a safe thing to do security wise, no?
Fedora ships a virtualization environment, so while grub1 should "go away as soon as possible" in terms of Fedora's own use, having it around for situation 3 is not outside the scope of a reasonable request in support of Fedora's own virtualization stack. Therefore, I would take your argument as basically "We don't want it in the base OS any more, and we don't care about our virtualization stack, so go away." I don't think he missed the point at all, except maybe missing that some people don't care about supporting a reasonably functioning virtualization stack in Fedora.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
