Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qubes-Lite with KVM and Wayland

roscidus.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Qubes-Lite with KVM and Wayland

#31

Post by foobar33333 »

t0astbread wrote: post #29
foobar33333 wrote: post #21

Earlier quoted context omitted.

I tried running proxmox on my server for a while but I found it was more complex to do everything and I wasn't gaining any benefits from it since it looked very enterprise and multi machine focused. These days I use fedora coreos with podman/docker. I'm trying out virtual machines using libvirt and then virt manager on my desktop for control but I have not been able to find a way to do bridged networking.

Bridged networking in libvirt can be a bit of a pain but I've found that routed works pretty well. Also - if I'm not mistaken - libvirt's netfilter firewalling isn't available on bridged networks.

Is it possible to ssh in to a vm in a non bridged network? I thought you had to give the vm its own local ip on your network.

Re: Qubes-Lite with KVM and Wayland

#32

Post by fsflover »

effie wrote: post #15
xvector wrote: post #8

Earlier quoted context omitted.

I have been considering grabbing a Librem 14 and switching to Qubes as a daily. Could you elaborate on what you found cumbersome?

Qubes is very "opinionated" about how things work and provides a functional but very tightly-knit product that cannot be easily modified to suit your own needs. You have to accept their choices like a good nontechnical user does - you can't modify/replace components or use a modified security model easily. For example, with version 3.2 which I used for a while, one has to use the default disk setup (no ZFS or other c…

> Regarding security, Qubes makes some strange choices such giving the regular VM unix user root privileges accessible via simple passwordless sudo.

See here for details: https://www.qubes-os.org/doc/vm-sudo/

You can replace passwordless sudo with a secure user prompt: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless...

Re: Qubes-Lite with KVM and Wayland

#33

Post by [deleted] »

walrus01 wrote: post #16

The part about the qubes dom0 being 'outdated' is worrying, because one of the important things to think about for good Xen linux-on-linux (PV) performance is to use a recent kernel on the dom0, and recent version of xen. Even ultra conservative debian stable (buster, right now) uses something fairly up to date, and xen 4.11. I'd be concerned about using anything older than that.

[deleted]

Re: Qubes-Lite with KVM and Wayland

#34

Post by fsflover »

ncmncm wrote: post #23

I have been using Qubes for a couple of years. I was surprised at his description of his experience. I run it on an ASUS 4-core skylake laptop which has Intel integrated graphics on a 4k screen, and an NVidia thing I keep powered off. The only compatibility problems I find are that (1) ASUS BIOSes and UEFI only just barely tolerate one another, and (2) palm suppression on the touchpad doesn't work. I mapped a key to…

> I would rather see the dom0 running NixOS than ancient Fedora.

https://github.com/QubesOS/qubes-issues/issues/1919

> The only thing I have never got to work, at all, is clipboard operations between VMs. It announces it's doing something with various clipboards, but nothing apparent ever happens.

This sounds very strange, has been working flawlessly for me since forever. Perhaps you could fill a bug or ask at Qubes forums: https://qubes-os.discourse.group.

Re: Qubes-Lite with KVM and Wayland

#35

Post by fsflover »

indolering wrote: post #19
xvector wrote: post #8

Earlier quoted context omitted.

I have been considering grabbing a Librem 14 and switching to Qubes as a daily. Could you elaborate on what you found cumbersome?

> I have been considering grabbing a Librem 14 and switching to Qubes as a daily FWIW, I did the same thing and was unhappy with the result. The Librem hardware wasn't great quality and Qubes really requires a massive desktop to run well. And if you are paranoid enough to need Qubes, then you want ECC memory to defend against side channel attacks.

Not sure what you are talking about. Any details? Qubes runs smoothly on my Librem 15 with 32 GB RAM.

Re: Qubes-Lite with KVM and Wayland

#36

Post by fsflover »

> it would be nice to be able to do video conferencing these days

Works fine for me, except bluetooth (see below). What's the problem with it?

> bluetooth would be handy

A dedicated Audio VM is coming in 4.1: https://www.qubes-os.org/news/2020/03/18/gui-domain/#audio-d.... Related issue: https://github.com/QubesOS/qubes-issues/issues/1590.

Re: Qubes-Lite with KVM and Wayland

#37

Post by gwd »

1996 wrote: post #5
Nojlk wrote: post #3

Earlier quoted context omitted.

The Qubes people don't recommend doing GPU passthrough because of the security implications. As for the OP, I feel like if somebody cares about security, they shouldn't be doing any of this. Trying to come up with some self-designed hodgepodge of things isn't really enough security-wise, even if you do use VMs, and I'd find it hard to trust something like this as a platform to do anything important on.

> The Qubes people don't recommend doing GPU passthrough because of the security implications. Why? DMA?

Basically, yes.

Theoretically, all modern systems have IOMMUs, which are supposed to be able to allow an operating system (or hypervisor in this case) to restrict what a device can do.

In practice, IOMMUs can't be trusted, for two reasons.

First, the implementations (i.e., the actual hardware) are frequently full of unpatchable security holes. It's not just the CPUs themselves that need to be correct; every chip in the PCI chain has to DTRT from a security perspective or risk opening up a vulnerability.

Secondly, particularly with GPUs, many systems have 'magic backdoors' that side-step the IOMMU systems completely. Frequently this is to make certain operations "faster" or "easier".

Basically, unless you have done your own audit and testing of the hardware you own (or someone you trust has done the same thing), you have to more or less assume that a malicious guest with control of a physical device could break out of the system.

In Xen's SUPPORT.md document, we very carefully tried to balance this:

Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use [PCI passthrough] to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).

Re: Qubes-Lite with KVM and Wayland

#38

Post by w0utert »

KirillPanov wrote: post #30
slaymaker1907 wrote: post #28

Earlier quoted context omitted.

Can you explain what virtwl.ko is? I tried looking it up but couldn't find anything even remotely relevant when searching for that term.

Here's the link from the article: https://alyssa.is/using-virtio-wl/ It doesn't really have a better name. It was written by Google to allow Android apps to run inside a VM on ChromeOS. Although it does work with mainline Linux, Google is understandably not motivated to invest effort in branding virtwl.ko with a non-cryptic name, or marketing it as its own project independent of ChromeOS. AFIAK nobody outside of Goog…

Good explanation in the linked article!

This way of using Wayland and VM's seems very interesting and useful. What I'm wondering though, is whether it would be realistically possible to also expose some kind of GPU acceleration to clients in VM's, for example by means of a virtual OpenGL adapter such as VirGL, which itself uses virtio on top of the host GPU driver. This would not get you anything near the performance required for games, but it should be way better than software rendering inside the clients. Do you think something like this would be possible already?

Re: Qubes-Lite with KVM and Wayland

#39

Post by zajio1am »

KirillPanov wrote: post #26

virtwl.ko really is the killer app for Wayland [Edit: virtwl.ko lets a wayland client inside a VM connect to a wayland server which is on the same machine but outside the VM]. I mean without it, all the noise about Wayland being more secure than X11 is just noise, because Wayland doesn't do remote display, so you have to allow that evil app you're scared of to run on the same machine as the compositor and all your ot…

> I mean without it, all the noise about Wayland being more secure than X11 is just noise, because Wayland doesn't do remote display, so you have to allow that evil app you're scared of to run on the same machine as the compositor and all your other apps, and you can't even put it in a VM.

But you can run it with different UID.

Re: Qubes-Lite with KVM and Wayland

#40

Post by effie »

fsflover wrote: post #32
effie wrote: post #15

Earlier quoted context omitted.

Qubes is very "opinionated" about how things work and provides a functional but very tightly-knit product that cannot be easily modified to suit your own needs. You have to accept their choices like a good nontechnical user does - you can't modify/replace components or use a modified security model easily. For example, with version 3.2 which I used for a while, one has to use the default disk setup (no ZFS or other c…

> Regarding security, Qubes makes some strange choices such giving the regular VM unix user root privileges accessible via simple passwordless sudo. See here for details: https://www.qubes-os.org/doc/vm-sudo/ You can replace passwordless sudo with a secure user prompt: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless...

Notice how that argument starts with the conclusion "In Qubes VMs there is no point in isolating the root account" and proceeds to rationalize it, very poorly, by using some cherry picked examples where that may be true.

OK, an attacker capable to attack the hypervisor when running as root may be often "game over" if it runs as regular user. But that kind of attack is so rare, why is it the base of the argument at all?

Meanwhile your browser/other big SV application/script from Github can become root whenever it wants, or by accident. It can send contents of the whole VM over the Internet to anybody. Or an honest bug in it can destroy your whole VM. This is why the unix privilege separation or even more capable MAC systems exist. Seriously, running untrusted applications with root access is a braindead idea.

Post reply on HN