FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-22-2011, 07:39 PM
Peter Jones
 
Default grub / grub2 conflicts

On 09/22/2011 03:27 PM, Richard W.M. Jones wrote:
> On Thu, Sep 22, 2011 at 02:51:40PM -0400, Peter Jones wrote:
>> Oh, my mistake. That being beside the point, it pretty much means
>> any VM created in a previous OS release won't work. In any case I
>> totally disagree with your idea of security, as I mentioned at the
>> time. It makes things worse, not better.
>
> Not running random code from untrusted guests makes things worse?

Having more things installed on the host means a larger attack surface.

>> And that's still ignoring that grub1 needs to completely go away.
>
> It's not going to completely go away until such guests completely go
> away. People use virtualization precisely because it allows them to
> continue to run very old operating systems. Or even supported ones
> like RHEL 6 (using grub1 until 2017-2020).

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.

--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 08:07 PM
Doug Ledford
 
Default grub / grub2 conflicts

----- 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@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 08:44 PM
Peter Jones
 
Default grub / grub2 conflicts

On 09/22/2011 02:47 PM, Richard W.M. Jones wrote:

> There is a further issue #2, quite orthogonal, which is that grub
> (upstream) doesn't support offline installation. This is a bug in
> grub 1& 2 which really should be taken upstream.

You're still missing the point here. This wasn't a design feature of grub
or of grub2. It's not a bug, it's a thing nobody has ever planned for.
Additionally, there is no grub 1 upstream. You're never going to convince
any "upstream" to change this, because there's nobody working on it. There
hasn't been an upstream since 2005. It needs to be jettisoned into space.

> Nevertheless, it's quite possible to use grub1 offline on compatible
> guests. We don't really need to "prove" this, because we do it, and
> test the results, and we publish everything we do in open source code.

And that's not going to be possible when we don't install grub1 on the host
system.

--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 09:08 PM
Matthew Garrett
 
Default grub / grub2 conflicts

On Thu, Sep 22, 2011 at 09:23:40PM +0200, Miloslav Trmańć wrote:
> On Thu, Sep 22, 2011 at 8:40 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Thu, Sep 22, 2011 at 07:38:54PM +0100, Richard W.M. Jones wrote:
> >> On Thu, Sep 22, 2011 at 05:37:39PM +0100, Matthew Garrett wrote:
> >> We allow you to inspect the guest to find the OS version, and even
> >> versions of individual packages installed in it.
> >
> > The package version of grub does nothing to tell you which version of
> > grub is actually installed in the boot sector.
>
> That doesn't matter: When libguestfs runs its installation of grub,
> the boot sector will be overwritten. What matters is the versions of
> stage1/1.5/2 files in the guest, which is adequately described by
> identifying the RPM.

And now you're assuming that sector list will always be in the same
place. Which also isn't guaranteed.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-22-2011, 09:36 PM
Peter Jones
 
Default grub / grub2 conflicts

On 09/22/2011 04:07 PM, Doug Ledford wrote:

> 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.

You're basically arguing that we should never remove any software from Fedora
in case it's used in a virtual machine hosted on a Fedora machine.

This is not a workable scenario.

--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 02:26 AM
Kevin Kofler
 
Default grub / grub2 conflicts

Peter Jones wrote:
> You're basically arguing that we should never remove any software from
> Fedora in case it's used in a virtual machine hosted on a Fedora machine.
>
> This is not a workable scenario.

Why, if the virtualization folks are willing to pick up maintainership? You
won't have to maintain the old GRUB 1 anymore.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 11:54 AM
Doug Ledford
 
Default grub / grub2 conflicts

----- Original Message -----
> You're basically arguing that we should never remove any software
> from Fedora
> in case it's used in a virtual machine hosted on a Fedora machine.
>
> This is not a workable scenario.

OMG Peter, can you intentionally conflate any more molehills into mountains? Do you even believe the stuff you are spewing? Of course it doesn't apply to all software, but the boot loader is an acknowledged special case of *all* installations, and it's something necessary to manage vm images, that does not conflate to all software unless you are just trying to be pissy.

Regardless, this is my suggestion Richard:

Grab the current grub package and add the source tarball to libguestfs
Grab the current grub2 package and add the source tarball to libguestfs
Build grub and grub2 as part of the libguestfs package
Install the grub and grub2 binaries as /usr/libexec/vm-grub{,2} and remove all the other grub/grub2 files (they aren't needed)
Maintain the binaries in libguestfs and fix any problems you find with specific guest OSes in your own package. This has the side benefit that libguestfs will be more portable as a result because you won't care about the host OSes boot loader installation (or lack thereof).
If anyone complains about a grub/grub2 binary in libguestfs, tell them it's a necessary tool the base OS didn't want to provide reliably so you did what was necessary.

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 02:20 PM
Peter Jones
 
Default grub / grub2 conflicts

On 09/23/2011 07:54 AM, Doug Ledford wrote:
> ----- Original Message -----
>> You're basically arguing that we should never remove any software
>> from Fedora
>> in case it's used in a virtual machine hosted on a Fedora machine.
>>
>> This is not a workable scenario.
>
> OMG Peter, can you intentionally conflate any more molehills into mountains?
> Do you even believe the stuff you are spewing? Of course it doesn't apply to
> all software, but the boot loader is an acknowledged special case of *all*
> installations, and it's something necessary to manage vm images, that does
> not conflate to all software unless you are just trying to be pissy.

I don't in any way buy that it's "necessary to manage vm images"; it's
used because of a bad design, not because it's necessary. But thanks for the
pile of insults instead of listening to what's been said in disagreement.

> Grab the current grub package and add the source tarball to libguestfs Grab
> the current grub2 package and add the source tarball to libguestfs Build grub
> and grub2 as part of the libguestfs package Install the grub and grub2
> binaries as /usr/libexec/vm-grub{,2} and remove all the other grub/grub2
> files (they aren't needed) Maintain the binaries in libguestfs and fix any
> problems you find with specific guest OSes in your own package. This has the
> side benefit that libguestfs will be more portable as a result because you
> won't care about the host OSes boot loader installation (or lack thereof). If
> anyone complains about a grub/grub2 binary in libguestfs, tell them it's a
> necessary tool the base OS didn't want to provide reliably so you did what
> was necessary.

If you don't package the tools as "grub-install" and "grub" in root's PATH,
I don't honestly have much objection to this, with some caveats. Not least,
there's some work required just to make that plan work. Also, you probably
do want the patches that represent most of a decade of maintenance work.

--
Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 08:28 PM
Doug Ledford
 
Default grub / grub2 conflicts

----- Original Message -----
> it's
> used because of a bad design,

It's not a bad design, it's the *right* design. Being able to rescue a guest that can't boot without resorting to a rescue cd boot of the guest vm is a worthwhile goal and this is part of that. The two alternative designs (guest code in guest vm, guest code in host vm) were both shown to be inferior designs (the first because the guest vm might not be bootable and requires booting up the guest vm which is highly undesirable if the user is simply attempting an offline modification of the vm, the second because that's a huge gaping security cluster fuck).

> not because it's necessary.

It's just as necessary as any of the other rescue tools we put on rescue CDs.

--
Doug Ledford <dledford@redhat.com>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 09-23-2011, 08:51 PM
Matthew Garrett
 
Default grub / grub2 conflicts

On Fri, Sep 23, 2011 at 04:28:30PM -0400, Doug Ledford wrote:
> ----- Original Message -----
> > it's
> > used because of a bad design,
>
>
> It's not a bad design, it's the *right* design. Being able to rescue
> a guest that can't boot without resorting to a rescue cd boot of the
> guest vm is a worthwhile goal and this is part of that. The two
> alternative designs (guest code in guest vm, guest code in host vm)
> were both shown to be inferior designs (the first because the guest vm
> might not be bootable and requires booting up the guest vm which is
> highly undesirable if the user is simply attempting an offline
> modification of the vm, the second because that's a huge gaping
> security cluster fuck).

It's a bad design because it asserts something (grub versions are
compatible with each other) that isn't true (they're not). I don't have
any idea how to solve this given the constraints that are being imposed,
but this approach certainly isn't a solution.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org