Live data from Hacker News

Qubes-Lite with KVM and Wayland

roscidus.com

41–50 of 52 posts

Re: Qubes-Lite with KVM and Wayland

#41
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…

> 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. It's worth mentioning that Qubes has good reason for this. A big part of the purpose for their existence is to…

Qubes provides a very specific product. Whether it helps to "protect journalists and others who would greatly benefit from enhanced security" depends on user level of knowledge and the ways he uses the computer. If the user does not know much about security, Qubes may help to isolate different tasks in VMs, but that is not a panacea. He may still use it wrong in single VM, for example leave the passwordless sudo on.

Serious security-seeking user needs to educate himself about how the computer and internet works, about operational security, pervasive tracking, typical attacks etc, not just use a product and call it a day. Only so educated user can decide if the Qubes with its benefits/drawbacks is worth it.

Re: Qubes-Lite with KVM and Wayland

#42
post #40

Earlier quoted context omitted.

> 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 al…

In Qubes, you typically don't care if your untrusted application compromises the (untrusted) virtual machine. This is the whole point of the virtualization and separating your work into security domains. See also: https://xkcd.com/1200/.

Anyway, Qubes team is not against such kinds of isolation: https://qubes-os.discourse.group/t/isolation-within-the-same....

Re: Qubes-Lite with KVM and Wayland

#43

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.

Qubes OS provides its own kernel for dom0, which is more recent than where the Fedora distro in dom0 stopped.

https://qubes-os.discourse.group/t/outdated-dom0-is-it-a-pro...

Re: Qubes-Lite with KVM and Wayland

#44
post #41

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. It's worth mentioning that Qubes has good reason for this. A big part of the purpose for their existence is to…

Qubes provides a very specific product. Whether it helps to "protect journalists and others who would greatly benefit from enhanced security" depends on user level of knowledge and the ways he uses the computer. If the user does not know much about security, Qubes may help to isolate different tasks in VMs, but that is not a panacea. He may still use it wrong in single VM, for example leave the passwordless sudo on.…

Of course. But there is a difference between expecting someone to learn what it does, and why it does it, and expecting them to learn how to implement/modify it themselves.

People have work to do, work that has computers as a tool, not a goal. Lowering the bar from "Learn the exploits" to "Be careful and stay in the lines" is a Good Thing, imho.

Qubes provides an effective framework to say "This is how to use it, this is what you should be aware of, don't do this".

Re: Qubes-Lite with KVM and Wayland

#45
post #4

I used qubes for a while, but found it kind of cumbersome to do most things, and I never got over the hump. Since then I've been using proxmox, and I'm at the point where I don't use the gui anymore, I just do everything from the command line. You can do VM things (like run macos in a vm), but I do most things in lxc containers. It would be kind of nice if proxmox had something like a Dockerfile, but with local conta…

So like, you are using Proxmox as your main OS/desktop? And then doing application (eg firefox for browsing, etc) things in in proxmox LXC containers? If so, that is pretty interesting... Although, using LXD with Ubuntu is totally painless and easy as well..

Actually, it went sort of like this:

I used qubes as a desktop os, but it was a little clunky. Like the copy/paste or moving stuff between the vms.

But the main problem was I couldn't ssh INTO the qubes machine, and I couldn't really run server kinds of things (though maybe it was possible to dig into the networking and the firewall vm).

When I tried proxmox, it was more set up for server kinds of things. For example, all the VMs showed up as machines on my local network. I started to make it a desktop, but then backed off. I decided to leave the debian main os vanilla. Instead I made it a server. And I got away from VMs and use containers.

I do have a macos vm that I remote into though. It's a copy of my laptop which I haven't used as much the last year.

Re: Qubes-Lite with KVM and Wayland

#46
post #40

Earlier quoted context omitted.

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 al…

In Qubes, you typically don't care if your untrusted application compromises the (untrusted) virtual machine. This is the whole point of the virtualization and separating your work into security domains. See also: https://xkcd.com/1200/ . Anyway, Qubes team is not against such kinds of isolation: https://qubes-os.discourse.group/t/isolation-within-the-same... .

> In Qubes, you typically don't care if your untrusted application compromises the (untrusted) virtual machine.

For that to be true, one would have to run each application in a dedicated VM. A great idea, but Qubes does not recommend that for efficiency reasons. It does pose performance and usability challenges which is why most people do not use it that way. So yes, you do care about applications in single VM not snooping/manipulating each other. Luckily there are standard unix and MAC mechanisms to isolate them.

Re: Qubes-Lite with KVM and Wayland

#47
post #46

Earlier quoted context omitted.

In Qubes, you typically don't care if your untrusted application compromises the (untrusted) virtual machine. This is the whole point of the virtualization and separating your work into security domains. See also: https://xkcd.com/1200/ . Anyway, Qubes team is not against such kinds of isolation: https://qubes-os.discourse.group/t/isolation-within-the-same... .

> In Qubes, you typically don't care if your untrusted application compromises the (untrusted) virtual machine. For that to be true, one would have to run each application in a dedicated VM. A great idea, but Qubes does not recommend that for efficiency reasons. It does pose performance and usability challenges which is why most people do not use it that way. So yes, you do care about applications in single VM not sn…

You don't run each application in a dedicated VM, but you have security domains, each of which have equally (un)trusted applications.

Also, there are disposable VMs for truly untrusted things.

Re: Qubes-Lite with KVM and Wayland

#48

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.

Like I said:

> In theory you might be able to run the evil app under another userid, but in practice this often breaks in all sorts of ways because people just don't do that very often so it exposes untested codepaths in UI/widget/GUI libraries.

Regardless, privilege escalation bugs are a dime a dozen these days. Running evil things as another userid is no substitute for moving them into a VM or off of the machine completely.

Re: Qubes-Lite with KVM and Wayland

#49
post #18
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…

> graphically intensive applications in VMs was sluggish Just as a datapoint youtube or vlc seem to work well enough. The sluggishness is definitely noticeable though. As a developer it encourages me to optimize the display performance of my web applications. If it performs ok on Qubes it's liquid smooth on my 3+ year old android phone. Take that as you will... > internet/firewall/audio would randomly stop working wh…

> Just as a datapoint youtube or vlc seem to work well enough.

As another datapoint, when I installed Qubes about six months ago on a i6600k with 16GB RAM, in the default VM and browser, YouTube was basically unwatchable.

Re: Qubes-Lite with KVM and Wayland

#50

Earlier quoted context omitted.

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.

Sorry, I didn't see that comment earlier!

Routed turns your virtualization host into a router for a separate network on which your VMs live (afaik). So in order to reach that network you have to define static routes that ultimately lead to the virtual interface set up by libvirt.

When you start your routed network (with net-start), libvirt should set up a static route on the host machine automatically. You can see this route with "ip route". To make it available to all hosts on your network, you can configure a static route on your (physical) network's router that covers the IP address range of the virtual routed network and has the (physical) IP address of your virtualization host set as the gateway.

For example: Assume your virtualization host has 10.0.0.10 as its address in your "real" network and your virtual routed network covers 10.0.1.0/24. You would have to set up a static route on your "real" router that says "route 10.0.1.0/24 to 10.0.0.10".

Libvirt automatically sets up a route in the local routing table of your virtualization host that says "route 10.0.1.0/24 to virbr0" (or whatever your network's virtual interface is called).

Then, if everything worked, you should be able to connect to your VMs in 10.0.1.0/24 directly.

Post reply on HN