[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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
>
> iQEcBAEBCAAGBQJWt69BAAoJENuP0xzK19csfHYH/2jdswteTgoh256NADdWocI3
> fS8icSEMzhsvOXJ445iuKH8PZHrUjp4zBDgWR/OOQJU0Cp5boz95WR4Ve7TO7ecf
> vZLVhDBH1wZq/MgzKk9QvzC2OYrvnTHI8k8OMkZqa1MCDFWmxgfPJ9eK8KbOdF98
> OXoNebptcy7XOC/utyS/laR/GpuH3Gc2qnS20ehSsz/Fys6CQHU71JKeRDqVKLWo
> F7lNK8UN6JCTPkagqD338Fbl8vF1qXP7n7MPWmnf1PVgRrlEny+bnQqAJLJ5/VV+
> 10LrTZAqWYlNeC8/3Yjzu3AesBbAHIt4G208+EYxlOpgvBCt3tBRbcRKITJlHUY=
> =IyDx
> -----END PGP SIGNATURE-----



-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.