Docker vs. QubesOS

General Discussion
1

I’m going to be a bit of an annoying noob, I read this article about how QubesOS stacks up against VM, however it does not address Docker containers (though it does address older types of containers). If we are to disregard the insecurity of the underlying OS, docker containers do seem to have some advantages over traditional VMs: they are lighter weight, and they seem more secure. It is built into docker that it is suppose to be very difficult to “escape” a docker container. In addition you can get hardware accelerated containers with nvidia-docker. Docker containers are quite disposable as well.

Ignoring the insecurity of the underlying OS (or at least, discarding the principle that the container is only as secure as the OS it runs on), what are the advantages of Qubes OS over Docker, or the advantages of Docker of Qubes OS?

1 Like
2

Docker is not security boundary IMO. It’s basically just a kind of chroot or jail. It shares the running host kernel.

On a related note, there was something resembling Qubes OS running Docker containers, called RancherOS.

I’d love to see more competition in this field, for example utilizing KVM. Qubes seems to be lonely giant dominating this OS approach.

4 Likes
3
2 Likes
4

Hi @TheFloatingBrain - it’s a good question. I dont have time for
anything but a quick comment atm.

Of course, the way you have framed it, deliberately ignores
one of the key advantages of Qubes, not using OS virtualisation.

Otherwise, Qubes offers a unified framework for working with the qubes,
and for passing data between them within a security framework.
Compare “qvm-copy” with “docker cp”.

Qubes is also fundamentally aimed at the desktop, and provides tools to
make that experience as workable as possible, again within a security
framework.
Docker can run graphical programs, but they (generally) work by mounting
the Xserver socket in the container - so the container has direct access
to the Xserver. This means that the container has access to all of the
screen, and access to clipboard and input devices. Your GUI enabled
container can log all keystrokes, wherever they originate.
Qubes deliberately aims to isolate qubes so this is not possible.

I use docker - it’s good. But it aims at something different from Qubes,
and has a different place.

I never presume to speak for the Qubes team.
When I comment here or in the mailing list I speak for myself.

6 Likes
5

SpectrumOS seems to be serious attempt, with thought out design and some sort of funding. Very interesting stuff, thanks for pointing this out!

1 Like
6

I remember Spectrum - the online docs read like a pitch aimed at people
not well versed in Security/virtualisation.
And, of course, it worked in gaining funding.

I’ve not seen anything like a workable system as yet, so it’s difficult
to know where it will be going, and what it will be like once it
arrives.(If it does.)

2 Likes
7

Wow so many responses!

I looked at everything you all sent me, it all looks really interesting, and sent some of what you all sent me to others. I will respond to things individually.

8

I am looking into rancher now, it looks really interesting. I would love to see more options as well, nix seems to have some similar benefits, spectrum building on it will have some as well. Spectrum seems to have more shared resources though? So I wonder if it will be less secure? Honestly I think containerization/modularity should be the future on desktop (and mobile)

9

This article is excellent I actually sent it too a few people.

In my search for a linux distro I have thought about installing Nix OS (right now I am thinking of nix, pop!, chimera, manjaro, qubes, and maybe elementary… cuz its pretty + rancher now).

I really want to separate gaming, dev, work, school, and personal while maintaining privacy, and to keep things containerized. The way linux spreads packages all over the system has always killed me. As a C++ developer, I think containers would be best with working with multiple tool chains, build systems, and sets of libraries.

10

You are correct about docker, it is possibly a little too granular for some cases, but I can see a potential ability to make a container have multiple applications.

I am somewhat curious about the security concerns of accessing a mouse or screen (though I can definitely see it for clipboard). Unless there was some hardcore hacking going on, I’m not sure how concerned I would be about someone accessing my screen or mouse, could you explain please? The best case I can see is modifying, say, a md5 confirmation hash, to verify something that was downloaded, but it could have been compromised in a lot of other ways that would be much easier.

11

I think it will be the future. Qubes OS is a pioneer in this field.

Not only this approach offers the obvious security benefits, but to me it is much wider concept. Immutable environments, clean data management, hardware layer abstraction etc.

1 Like
12

Oh I can agree with all that

13

Imagine one of your containers were compromised by an attacker. Every information that you view in any other container (e.g., some medical records sent to you by your doctor, a password stored in KeePass, some kind of API key shown on a web page, …) could now be acquired by an attacker. Often, merely looking at your screen is enough to learn about secrets (which is why some people use privacy screen films on their laptops when travelling).

Concerning the abuse of your mouse, think of what you could achieve on your system by only using the mouse. Navigate to the main menu, activate the on-screen keyboard and you basically have full code execution in any other container. Access to (trusted) input devices is game over for your security.

1 Like
14

I suppose it is possible to run separate X servers for containers (Xephyr or similar), but still there’s the fundamental problem: containers are interfacing the same Linux kernel “dom0” is running. I’d never ever trust such system.

15

I’ve a mostly related question for you all.

Imagine the scenario depicted in the diagram, assuming qubes running on a machine with at least two ethernet interfaces:

|= = = = = = = = = = = = = = = = = = = = = = = = = = = = =|
                        cloned    +-----+        +-----+     
                          from____| def |    ____| def |     
                             /    | tpl |   /    | tpl |     
                            v     +-----+  v     +-----+
                instance  +-----+        +-----+ +--------+
                    of____| dvm |     ___| dvm | | not    |
     +----+          /    | tpl |    /   | tpl | | expose |
     |    |  eth    v     +-----+   v    +-----+ | to     |
     | vl | +---+ +-------------+ +------------+ | web    | 
     | 10 |-|[0]|-|  sys-net    |-|  sys-fw    |-| appvms |
     |    | +---+ +-------------+ +------------+ +--------+ 
+--+ | == | ===============================================
|  | | s  |             cloned    +-----+        +-----+     
|  |-|  w |               from____| def |    ____| def |
|f |-| i  |                  /    | tpl |   /    | tpl |
| w|-|  t |                 v     +-----+  v     +-----+
|  |-| c  |     instance  +-----+        +-----+ +--------+
|  | |  h |         of____| dvm |     ___| dvm | | expose |
+--+ | == |          /    | tpl |    /   | tpl | | to     |
     |    |  eth    v     +-----+   v    +-----+ | web    |
     | vl | +---+ +-------------+ +------------+ | docker |
     | 20 |-|[1]|-|  svcs-net   |-|  svcs-fw   |-| hvm    |
     |    | +---+ +-------------+ +------------+ +--------+
     +----+
|= = = = = = = = = = = = = = = = = = = = = = = = = = = = =|

Briefly, let me clarify what’s happening here:

  • the default template (def tpl) that the disposable templates (dvm tpl) sys-net and sys-firewall (sys-fw) use were cloned
  • the clones were labelled with a prefix indicating they for the sevices (svcs) environment
  • “normal” app vms use sys-fw for net access
  • a new, standalone hvm called ‘svcs-docker’ uses svcs-fw which uses svcs-net for net access, which runs containers
  • note that this is an install from an image, not a cloned template, and does not run the qubes core agent
  • the “sys” environment uplinks via sys-net’s interface to vlan 10, and “svcs” 20
  • vlan 10 and 20 are in separate zones on the physical firewall/router that the physical switch uplinks to
  • the physical firewall, svcs-net’s /rw/config/rc.local and svcs-fw’s qubes-firewall-user-script are edited to allow traffic inbound to the docker host only on specific ports from specific sources

So the question is: in this scenario, what are the security ‘gotchas’ that one might run into?

If a container is exposed to an external network this way and becomes totally conpromised to the point where the adversary has root in svcs-docker, which should be entirely “qubes-unaware,” could this lead to a compromise in dom0?

I don’t claim to be nearly as versed in security as the people here, but know enough to make potentially catastrophic changes to things, so I’m reaching out here to see how silly this idea could be.

Thanks!

P.S. - As soon as I get my salt config tidy for implementing the above setup, I’ll share with whoever wants a go at it, unless it turns out to be a terrible idea, of course.

16

Actually there’s…not exactly a sister-project, let’s call it a cousin-project of Qubes called OpenXT (and a productized version of that called SecureView Workstation). Both projects run user VMs (domUs) and a coordinating VM (dom0) on top of Xen. The targeted audience for OpenXT/SecureView Workstation is a little different, mostly governmental/intelligence (perhaps some corporate).

Primary selling point appears to be getting authorization for handling different levels of classified data on the same hardware. So…compartmentalization. :slight_smile:

B

17

Seems Qubes is to a standard distribution as OOP is to K&R C.
Would wayland ever replace the xorg in Qubes?

18

It’s enjoyable having a scripts to cascade windows across qubes, but inter-gui comms seem to be a security risk.

19
20

Thanks for the link.