[Libguestfs] virt-sysprep future

[Richard W.M. Jones]

On Sat, Mar 17, 2012 at 08:16:03PM +0800, Wanlong Gao wrote:
> On 03/17/2012 07:49 PM, Richard W.M. Jones wrote:
> 
> > On Sat, Mar 17, 2012 at 06:59:34PM +0800, Wanlong Gao wrote:
> >> Does RedHat has a plan to support NBD in RHEL in the future?
> > 
> > Not as far as I know.
> > 
> > guestmount is fast enough for me.  With inspection:
> > 
> > $ time sh -c 'guestmount -a /dev/vg_pin/F16x64 -i /tmp/mnt; fusermount -u /tmp/mnt'
> > 
> > real   0m9.999s
> > user   0m0.081s
> > sys    0m0.377s
> > 
> > Without inspection:
> > 
> > $ time sh -c 'guestmount -a /dev/vg_pin/F16x64 -m /dev/vg_f16x64/lv_root /tmp/mnt; fusermount -u /tmp/mnt'
> > 
> > real   0m6.681s
> > user   0m0.074s
> > sys    0m0.339s
> > 
> > Currently virt-sysprep runs libguestfs twice (once for inspection,
> > once to mount).  A virt-sysprep that was rewritten not to be a shell
> > script would only run libguestfs once, so there would be ~10 second
> > overhead.  This overhead is insignificant compared to the downsides of
> > using nbd: having to run as root, (in)security, not supporting all
> > guests, creating host device nodes, etc.
> 
> [root at Allen ~]# time sh -c 'qemu-nbd -c /dev/nbd0 /dev/sda6; mount /dev/nbd0 ./tmp; umount ./tmp'
> 
> real	0m0.146s
> user	0m0.009s
> sys	0m0.005s

You ought to add kpartx and vgscan in there, for a realistic guest.
No, it still won't (quite) be 6-10 seconds.  That time is the
difference the two methods.  The real time for a full virt-sysprep run
will be many seconds or minutes.

> yes, "having run as root" is one of the  shortcomings.

> I can't get why nbd causes security problem, do you mean data
> corruptions in muti-access?

NBD isn't a security issue, but mounting untrusted guest filesystems
on your host kernel might be.  There's nothing to protect your host
(and other guests) from an exploit, and you need to trust that every
filesystem driver in your host kernel is hardened against malicious
filesystems.  When you use the 'mount' command above with the '-t'
option, blkid "helpfully" scanned the untrusted disk for a signature
and mounted the guest using that filesystem type; it could have been
*any* filesystem type, even really obscure and unexpected ones.
Filesystems are only the beginning; LVM metadata is another rich
source of problems/exploits.

The argument against mounting on the host will be even stronger when
we add the option of using libvirt with libguestfs.  Then you'll be
able to hide the untrusted guest in an SVirt [SELinux] container, with
cgroups for resource control.

> I can't understand the "not supporting all guest", since libguestfs
> points to look into the guest disk image, the concept of just read
> the disk images' format head is better.

Sure, but now try a guest that contains volume groups which conflict
with the host.  You can (nowadays[1]) mount such VGs using UUIDs, but
you have to find the UUIDs first -- complicated -- and you have to
trust that the guest's LVM metadata didn't name any of your host PVs,
either accidentally or maliciously.

Rich.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=207470

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora