Consider adopting containers for Qubes

[qubesuser]

I think it would be interesting to consider making Qubes "qubes" be Linux containers instead of VMs, to be assigned to Xen VM either in 1:1 or N:1 fashion.

Currently it is desirable to split activities into different "qubes" as much as possible for security/isolation reasons; however, RAM usage depends on the number of active "qubes" since they are VMs, which means that a user that follows such a strategy could eventually run out of RAM and be forced to merge VM filesystems manually.

Instead, if each "qube" were a container, the user could create lots of containers and assign them 1:1 to VMs and when he runs out of RAM, he can then decide which containers don't actually need security isolation from each other and assign them to the same VM with just a single setting change and without actually changing behavior in any way.

There is also a security advantage since with containers programs running in the "qube" would no longer have "real" local root and thus a Linux local exploit would be needed in addition to a Xen exploit to break security, while still freely giving container root to the qube.

Furthermore using containers might allow to reuse the existing rich ecosystem of container-related infrastructure and projects (all the things built around Docker, LXC, Kubernetes, etc.) potentially reducing the Qubes-specific development necessary while offering more features.

Of course there would still need to be support for "raw" VMs both for HVM and for custom Linux setups that don't work in a container.

Finally, it would be possible to run Qubes in a limited security mode where virtualization is not supported and on already installed Linux distributions.

The downside is of course the significant work that would be required to implement this change.

[marmarek]

Finally, it would be possible to run Qubes in a limited security mode where virtualization is not supported and on already installed Linux distributions.

The downside is of course the significant work that would be required to implement this change.

Those two points are the reason why we don't this. We already have enough work with making Qubes OS more secure, so we don't need additional tasks with making a less secure version.

As for containers usage inside VMs, it works like on any other system - you can simply install docker or similar in a VM (preferably standalone VM).

[marmarek]

Finally, it would be possible to run Qubes in a limited security mode where virtualization is not supported and on already installed Linux distributions.

The downside is of course the significant work that would be required to implement this change.

Those two points are the reason why we don't this. We already have enough work with making Qubes OS more secure, so we don't need additional tasks with making a less secure version.

As for containers usage inside VMs, it works like on any other system - you can simply install docker or similar in a VM (preferably standalone VM).

[eug48]

A possible advantage of a container-based version of Qubes not mentioned above is to make Qubes development easier, since one could run a development build of Qubes on one's main workstation to work on or test management GUI features for example.

[eug48]

A possible advantage of a container-based version of Qubes not mentioned above is to make Qubes development easier, since one could run a development build of Qubes on one's main workstation to work on or test management GUI features for example.

[andrewdavidwong]

A possible advantage of a container-based version of Qubes not mentioned above is to make Qubes development easier, since one could run a development build of Qubes on one's main workstation to work on or test management GUI features for example.

The standard recommendation for this is to have a dedicated hardware unit for developing on Qubes. However, it's also possible to run Qubes inside of itself as an HVM (PV-only inside the HVM).

[andrewdavidwong]

A possible advantage of a container-based version of Qubes not mentioned above is to make Qubes development easier, since one could run a development build of Qubes on one's main workstation to work on or test management GUI features for example.

The standard recommendation for this is to have a dedicated hardware unit for developing on Qubes. However, it's also possible to run Qubes inside of itself as an HVM (PV-only inside the HVM).

[eug48]

Thanks Andrew, I didn't know and that sounds very useful but although I got the R3.2 iso installed without problems it doesn't boot - after "Loading initial ramdisk" the screen goes black with cursor in the top-left and then the HVM turns off. guest-qubes-dev-vm.log uploaded to https://pastebin.com/raw/Kapq7NJB

[eug48]

Thanks Andrew, I didn't know and that sounds very useful but although I got the R3.2 iso installed without problems it doesn't boot - after "Loading initial ramdisk" the screen goes black with cursor in the top-left and then the HVM turns off. guest-qubes-dev-vm.log uploaded to https://pastebin.com/raw/Kapq7NJB

[jpouellet]

Thanks Andrew, I didn't know and that sounds very useful but although I got the R3.2 iso installed without problems it doesn't boot - after "Loading initial ramdisk" the screen goes black with cursor in the top-left and then the HVM turns off. guest-qubes-dev-vm.log uploaded to https://pastebin.com/raw/Kapq7NJB

@eug48 Such questions should be asked on https://www.qubes-os.org/mailing-lists/#qubes-users

[jpouellet]

Thanks Andrew, I didn't know and that sounds very useful but although I got the R3.2 iso installed without problems it doesn't boot - after "Loading initial ramdisk" the screen goes black with cursor in the top-left and then the HVM turns off. guest-qubes-dev-vm.log uploaded to https://pastebin.com/raw/Kapq7NJB

@eug48 Such questions should be asked on https://www.qubes-os.org/mailing-lists/#qubes-users