Reexamine the Qubes OS

[Kagami]

Qubes has a lot of pros compared to kagome:

• Xen hypervisor should be much more robust
• User-friendly, great concept of "secure by default" OS
• Memory is cheap so bigger memory use is not an issue

But there are also some cons:

• Marginal distro (based on Fedora) ⇒ less security audits/updates, compatible software, solutions, howtos, manuals, etc.

[Kagami]

https://www.youtube.com/watch?v=CqONg8w5nkw
http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Keynote.pdf
http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Tutorial.pdf

[timthelion]

I think that you should look at my security analysis of the container approach: http://subuser.org/security.html. To sumarise what I wrote there, I think that the container approach is not great security if you want to be "super secure" but it is a good compliment to Qubes style security. In Qubes, you really cannot run every application in its own VM, but you can run every application in it's own container, and then have only a few containters per VM.

Regards,
Tim

[Kagami]

Yes, thanks, I've already read this!

The great thing that coming in Qubes OS R3 is Hypervisor Abstraction Layer: they are going to implement abstraction which allows to use KVM/LXC/whatever backends to run application. So it should be possible in near future to run application using LXC with Qubes.

Though, I don't think it's mandatory. In 2015 it's very easy and common to have a computer with 32G of RAM (I have so and can easily expand up to 64G). Also, Xen have a memory dedup+compress options (though they seems to be disabled in Qubes). So I can easily imagine more than thirty applications running in the separate VMs at the same time. In my normal desktop experience I have less, so it's should be definetely possible.

---

I'm going to tell some more my thoughts about desktop Linux security.

For now (2015) desktop security is a (strangely) very poorly known area. Somehow we come to the situation where we blindly trust all our desktop programs. Fortunately things are starting to change. But it's hard to tell which solution will finally win.

As I mentioned in other issue (#3), some other people are slowly working over isolation using LXC-containers (systemd, coreos, sandstorm). It seems to be that in some future, solutions like subuser and kagome will no be longer needed because Linux init system/standart tools will already provide this functionality.

Saying that, I can't disagree with the fact that Qubes offers much stronger security guarantees than LXC will ever have. Of course, it's almost always better to have two solutions (LXC+Qubes) than only single one, so everyone would have benefit from a variety of defensive mechanisms. Though, human resources are limited, so I think it's better to help much more promising product. For now I'm not sure if Qubes is as good as it presented, because it's young, have small comminity, etc., but want to investigate it further for certain. Maybe it'd be better to bring community attention to Qubes than continue to harden current Linux distributions.

Thanks for reading this :)

[timthelion]

When I tried Qubes, I thought it was really amazingly good. Actually, I had no performance issues, my issues were 100% due to their use of fedora with some strang defaults(like flash player installed and enabled by default in firefox)...

[timthelion]

I also think that qubes is more promissing than Docker, because Docker Inc. hasn't been very professional about security. They released 1.0 without the user name spaces thing sorted out, and they have generally stated security as being the last priority. When there have been security flaws, Shykes has always responded by saying "meh, Docker isn't secure and we never said it was" (which is not really true). So I feel a bit bad having a security product based on Docker when they have such an attitude.

[Kagami]

Yea, it would be great to have polished popular user templates (they already have Debian and Arch). Also, I don't currently have an idea about how do they manage custom templates and custom templates updating.

Fully agree about LXC security. Seems like it will never have comparable level of security unlike true hypervisor because of how it's implemented. Also, I've heard that KVM implementation is also very "monolithic" unlike Xen: VMs in KVM is almost like a common processes.

[free5lot]

A note about Qubes OS. Qubes OS has two huge disadvantages (but I hope they'll be fixed):

1. No video acceleration for media playback, as player, flashplayer, and html5-player in browser run in external VM and only Dom0 has acceleration support, but it has no video player by design (and never will have by security design).
   Video acceleration doesn't work for Intel FOSS drivers, neither for proprietary nvidia/ati.
   Maybe HAL will solve it by offering a hypervisor that can give an acceleration to guest VM.

2. No acceleration in games (OpenGL/DirectX). But it's not so critical, as video (media) content playback is quite more essential feature for geeks than games.

Anyway, thank you Kagami for your effort with kagome!

[Kagami]

Intel made Clear Linux distro (https://clearlinux.org/) which is very similar to Qubes: HVM, apps are isolated from each other, aimed to provide better security via isolation, containers can easily be created and managed.

Seems like both type of solutions (lightweight containers and virtualization) are now rather popular as a way to manage software in Linux and we have CoreOS/RancherOS/Docker/systemd-machined/sandstorm and Qubes/Whonix/Clear Linux as two different but similar approaches.

I think soon there will be even more distros focused on isolation/security or even current distros will start to adopt isolation technics and Linux desktop security will get better.

[Kagami]

Discussion at: HN, LWN.

Looking at how some things in Docker are not optimal and given the other cons of kagome (badly written bunch of scripts is rather kludgy and unportable way to manage containers) I'll try Qubes 3.0 soon and check how it goes. 3.0-rc1 has been announced recently, I think I'll wait for rc2 and try it out.

[timthelion]

I am also having some second thoughts about subuser. I think that subuser is well written and I put a lot of time into every detail, but there are problems with the overall design. Our choice of Docker was indeed poor. Docker failed to address key design decisions such as user namespaces before 1.0 and now it seems to late to do things right(tm).

I re-wrote their buggy device management code and my changes were panic-commited mere hours before the 1.0 release without my code being properly reviewed and with changes that were not reviewed and which contained bugs. They did this, because they wanted to release 1.0 for some keynote speech at the first Dockercon. I really have a hard time seeing this as responsible release behavior. Furthermore, there is a "bug" in the device code. Devices are allowed within a container based on their major and minor number pairs. This means that if a device with numbers 33:44 exists and is allowed within the container, and then that device is removed, and a NEW device with the same number is created, that NEW random device will be allowed within the container. This bug is not documented (at least it wasn't last time I checked.). More importantly, however, when I remarked that the bug was not documented I was met with disinterest. I get the feeling that Docker Inc. is run by "professionals" who just don't have time for edge cases and race conditions.

[Kagami]

Interesting, thanks. Have you considered alternative solutions based on Linux lightweight containers?

There are:

• rkt from CoreOS project; they decided to replace huge Docker binary with their own tiny implementation
• Recently spawned LXD project by Canonical (don't know why do they need it though; it's funny how they added their own section to the former LXC site)
• Container capabilities of systemd; they should become mainstream quite soon
• Sandstorm project; not quite comparable, but these guys take the security properly.
• ...maybe some more

All of this except Sandstorm don't try to isolate GUI applications though. Seems like some things will be improved in Wayland but not all.

[timthelion]

Right now, I've put subuser into a sort of "dabble" mode. That means that I'll work on it a little bit when I get bored with my other projects but I won't work on it intensively. I believe that the projects by Gnone and Alex Larson will solve some of the GUI problems and while they aren't exactly the same as subuser, their solutions will provide good guidance. Wayland will help too, and I don't feel that it is necessary to come up with a hack solution for X which may or may not be secure when we can "do it right" with wayland and or one of the other X11 replacements.

Tim

[Kagami]

I believe that the projects by Gnone and Alex Larson will solve some of the GUI problems

Could you please give some links?

I don't feel that it is necessary to come up with a hack solution for X which may or may not be secure when we can "do it right"

Well, I agree that in long term we need mature secure solutions but what should we use right now? Wayland still looks like vaporware and maybe only in 3-5 years it'll become mainstream. Anyway, simple replacement of X with Wayland is not enough (see the link in previous message), in order to achieve good enough isolation entire infrastructure should be developed with security in mind. Otherwise we would get another Docker.

[Kagami]

There is also Subgraph OS and their oz wrapper which planned to implement exactly what I wanted with kagome.

[timthelion]

It seems like oz almost exactly the same as subuser... I wonder if they knew about subuser when they wrote it. I've sent them an issue asking...