Re: [MirageOS-devel] Mirage OS and Qubes OS integration

[Marek Marczykowski-GÃrecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Feb 07, 2016 at 10:33:39PM +0000, Thomas Leonard wrote:
> [ Adding mirageos-devel - can someone here comment about pvgrub2? ]
> 
> On 7 February 2016 at 20:55, Marek Marczykowski-GÃrecki
> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Hi Thomas,
> >
> > I'm just collecting what Qubes OS features are needed for better Mirage
> > OS integration, including sys-firewall usage. I see two major points for 
> > now:
> >
> > Installation
> > ============
> >
> > Currently Mirage OS is installed as a "kernel", then set as such for
> > some VM. Then whatever template is set for such VM, it will be simply
> > ignored by Mirage OS kernel.
> > Installation for additional "kernel" is currently possible only from
> > dom0, so user needs to execute some commands there. Currently the only
> > "nice" way to introduce software to dom0 is to install it as rpm
> > packages, from Qubes OS, or Fedora repository (or some custom one, but
> > it needs to be added manually in /etc/yum.repos.d). This means for
> > example executing some post-installation scripts in dom0 from such
> > package.
> >
> > We'd like to provide a way to install Mirage OS (or any other system for
> > that matter) without interacting with dom0 console. And do that secure
> > way, defined as: do not compromise security of the whole Qubes OS
> > installation, even if system/template/kernel installed that way is
> > malicious. Of course in such case every VM using it would be
> > compromised, but not the other VMs.
> >
> > The idea is to implement qrexec service[1], which will allow installing
> > *new* templates (but not modify existing one). The only things that
> > calling side will be able to set would be:
> >  - its name
> >  - root.img content
> >
> > Such templates would have "pvgrub2"[2] set as a kernel, so it will use
> > kernel from its root.img.
> >
> > How is that related to Mirage OS? It can be distributed/installed as
> > minimal root.img, containing just /boot directory with:
> >  - a Mirage OS binary
> >  - grub2 configuration starting it
> >
> > Why not installing it directly as a kernel (also using some new qrexec
> > service)? Two reasons:
> >  - VM kernel loaded from dom0 filesystem is parsed by a toolstack
> >    running there. While the attack surface is quite small here
> >    (probably only uncompressing code), it still exists
> 
> I don't think Mirage unikernels are actually compressed, and I think
> any decompression would happen inside the VM anyway. There may be
> other bugs however (there used to be some bugs in Xen's ARM loader
> code, I remember).
> 
> >  - having "Mirage OS" as a template would be more consistent with other
> >    options - you can choose whether you want sys-firewall on Fedora,
> >    Debian, or Mirage OS
> >
> > Then it would be up to some VM to download image, *verify its
> > signature/checksum*, and install it using provided qrexec service. It
> > can be also installed from DispVM.
> >
> > What do you think about it?
> 
> Another option would be for the user to create the new template from
> dom0, but specify the AppVM holding the image. That way, the user gets
> to pick the name. 

Actually picking the name is not an issue. We can have a prompt of it,
just after accepting qrexec service call (or even bundled in the same
window). Actually we thought about simply opening VM properties dialog
just after creating such template, to let user adjust it if needed.

> I think this is how boot ISOs are currently
> supported, right? Checking for updates should probably check with the
> same VM (the unikernel should not be able to update itself).

This may be a valid point.
But that may be non trivial to implement and somehow undermine gains of
using unikernel. Because you'll need to start full AppVM, just to start
another unikernel one...

But maybe there is a solution for that. First of all, in such setup, VM
(even unikernel based) has access to its image. So maybe such kernel can
have filesystem driver to be able to update that image (triggered by
some qrexec call)? Or even better: have two images in /boot - one for
actual unikernel runtime, and second one to just be an updater. That
second one can have totally different configuration, or even Linux
kernel with normal wget, gpg etc (if doing that in unikernel would be
hard). Then have some pvgrub2 configuration to choose the right image.

> For mirage-test, I made it so that the user in dom0 could set a flag
> allowing the dev AppVM to overwrite particular kernels, which is
> useful for testing.
> 
> > Firewall configuration
> > ======================
> >
> > Current Qubes firewall is quite iptables-specific. This is already
> > discussed here:
> > https://groups.google.com/d/msgid/qubes-devel/20160114163808.GW4892%40mail-itl
> >
> > If you have any suggestions there, please send it to that thread. Even
> > if that is just simple "looks good". The major reason for reworking
> > firewall configuration interface is exactly Mirage OS integration, so
> > please give some feedback there.
> >
> >
> > [1] https://github.com/QubesOS/qubes-issues/issues/1705
> > [2] https://www.qubes-os.org/doc/managing-vm-kernel/

- -- 
Best Regards,
Marek Marczykowski-GÃrecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWt+VZAAoJENuP0xzK19csbSIH/2PPxiPBQKdx/ii3hOJ6uUtO
1ZWQxLWdLC3QUT+adlYU7fVNqPDJ+Nks0MohThHPmm6v0nia2RYti8PbG2k95iRc
KYpYJ9lbnFSsCkruN+J12xB+RX8oFsymT18Mj9kQ+k9vEQjLUpB3p1ex6m8NFACZ
5Hapci+fBuZ5RnhLLKfvJTEDZoYchPYVtUYVRQsAQ3jaD74Wf47xZHNUkPIp9RXh
tWztKwwT4XLn+9lKecDFQbxH3Lpci78awhAKwBqcD8aq5b2rnbrkybwY7Hj2/o+D
NiTFkVhZSy7kghfxAVczIsjicaqMpGITK069Q/ecV8tD6je2dD8kkvlyXKC4vTY=
=9oMz
-----END PGP SIGNATURE-----

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel