Questions about merging Qubes with NixOS and about using Qubes and Xenserver together

[Thomas Strobel]

Hi devs!

I'm new to the Qubes developer mailing list, and so I want to start by
introducing myself before asking my questions.
I'm a software developer and entrepreneur and I'm building a cloud
platform which focuses on security and privacy.
I want use the technology behind Qubes to enable access to the cloud
platform from a secure and trusted environment within the OS.
I would be very thankful to learn about your thoughts and comments on
what I want to do.

I'm planning to merge Qubes with NixOS, the truly declarative Linux
operating system. NixOS has a centralized configuration system where the
whole OS is defined, and where e.g. KVM virtual machines or LXC
containers can be set up and managed as well. I want to use the
additional layer of abstraction that forms the declarative configuration
system of NixOS to also provide the domain configurations for Qubes.
That way the complexity of installing and managing different VMs can be
completely hidden from the user.
My question is whether you can tell me more about the patches that are
applied to the Qubes specific software? As I understand it, you're
taking RPM packages from Fedora and then modify these packages according
to your needs. As I would have to base the packages for NixOS onto
upstream developer packages, I do not have (and do not want to have) all
the Fedora specific patches by default. So I'm wondering which patches
did you add for Qubes, and why? Especially for the patches to Xen I
would be very interested in understanding which patches are Qubes
specific and which patches are general and are already on their way
upstream.
Also, are you be interested in the integration of Qubes into NixOS and
if so, how would it have to be done so that it is of some value and use
to you?

I'm also thinking about running Xenserver together with Qubes so that
domains can be managed and moved within a set of machines that run
Qubes. Has there been some work in that direction? What are your
concerns and thoughts about it from a security point of view? Also,
would it be better to have a virtual machine orchestration framework
that is based on libvirt instead of Xen?
I'm also thinking of what would be needed to have app streaming from a
server to a trusted remote client? In your opinion, would the spice
protocol be a good choice for that?

Are there plans to move the Qubes GUI software to KDE5? Is it just a
matter of recompilation or does the transition require major changes?

I think that's it for now :)

Many thanks in advance for your help!
Thomas

[cprise]

Hi Thomas,

I can't speak for ITL, but I'd be interested to hear what your centralized config system could do for Qubes users... keeping in mind that we are primarily interested in a marriage of strong endpoint security with a desktop platform.

As for what Qubes can do for you... Is it to enhance security for cloud admins and developers? To what extent does that user base desire a good desktop environment? And what can an OS that treats the network as inherently untrusted offer them?

[Marek Marczykowski-Górecki]

On Mon, Jan 05, 2015 at 10:37:24AM +0100, Thomas Strobel wrote:
> Hi devs!

Hi!

> I'm new to the Qubes developer mailing list, and so I want to start by
> introducing myself before asking my questions.
> I'm a software developer and entrepreneur and I'm building a cloud
> platform which focuses on security and privacy.
> I want use the technology behind Qubes to enable access to the cloud
> platform from a secure and trusted environment within the OS.
> I would be very thankful to learn about your thoughts and comments on
> what I want to do.
>
> I'm planning to merge Qubes with NixOS, the truly declarative Linux
> operating system. NixOS has a centralized configuration system where the
> whole OS is defined, and where e.g. KVM virtual machines or LXC
> containers can be set up and managed as well. I want to use the
> additional layer of abstraction that forms the declarative configuration
> system of NixOS to also provide the domain configurations for Qubes.
> That way the complexity of installing and managing different VMs can be
> completely hidden from the user.

I don't know NixOS, so can't give you any specific hints. But I can
answer your technical questions.

> My question is whether you can tell me more about the patches that are
> applied to the Qubes specific software? As I understand it, you're
> taking RPM packages from Fedora and then modify these packages according
> to your needs. As I would have to base the packages for NixOS onto
> upstream developer packages, I do not have (and do not want to have) all
> the Fedora specific patches by default. So I'm wondering which patches
> did you add for Qubes, and why?

Generally most of packages are used as is from Fedora. The only forked
packages are:
1. xen (vmm-xen repo)
In master branch (R3) you'll find patches divided into separate
directories - most of them are upstreamable (some are even backports
from unstable branch). Qubes-specific patches are in patches.qubes
directory. There are needed only in dom0, VM can use vanilla Xen libs.

2. libvirt - R3 only (core-libvirt repo)
Here are also some patches, but most of them (all?) are upstreamable
fixes. Some of them are already accepted in later libvirt version.

3. kernel (linux-kernel repo)
The kernel repo consists mostly of backported fixes (you'll find
comments in series-pvops.conf). Also some kernel options are required
(Xen drivers).

4. some KDE packages (desktop-linux-kde repo), xfwm4 (desktop-linux-xfce4 repo)
Mostly for custom window decorations (colorful frames, VM name in title
bar), and to disable some unneeded features (file management in dom0
etc).

> Especially for the patches to Xen I
> would be very interested in understanding which patches are Qubes
> specific and which patches are general and are already on their way
> upstream.
> Also, are you be interested in the integration of Qubes into NixOS and
> if so, how would it have to be done so that it is of some value and use
> to you?
>
> I'm also thinking about running Xenserver together with Qubes so that
> domains can be managed and moved within a set of machines that run
> Qubes. Has there been some work in that direction? What are your
> concerns and thoughts about it from a security point of view?

Qubes is meant to be a desktop system, not a server one, so we haven't
though of such features. There are a lot of things to think of to do in
securely (storage management, migration process integrity and
confidentiality etc).

> Also,
> would it be better to have a virtual machine orchestration framework
> that is based on libvirt instead of Xen?

This is what has been done in R3. Take a look here:
http://theinvisiblethings.blogspot.com/2013/06/qubes-os-r3-alpha-preview-odyssey-hal.html

> I'm also thinking of what would be needed to have app streaming from a
> server to a trusted remote client? In your opinion, would the spice
> protocol be a good choice for that?

Take a look at xpra project - it uses very similar approach as our GUI
virtualization.

> Are there plans to move the Qubes GUI software to KDE5? Is it just a
> matter of recompilation or does the transition require major changes?

I think only some minor modifications are required. Window decoration
plugin is already separate package, so if API is the same, the most
critical part should just work. Surely there will be needed some change
in custom configuration (disable file manager, unneeded plugins like
file indexing, network applet etc).

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