----- 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 <dledf...@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
