/cyber/ - Cyberpunk & Science Fiction

Eh, he's not talking about Qubes-style process isolation using VMs.

He's talking about running full OpenBSD in a VM as your main working environment.

You inherit all the bugs of hypervisor OS, you add all the bugs of your virtual OS.

I.e. intruder does not have to attack kernel+hypervisor, he can attack kernel OR hypervisor.

Instead of getting additional levels of security you just double your attack surface.

Also, you're expected to run Qubes itself on a real hardware too.

Qubes has to deal with the same issues to, but it's approach to security is not code correctness (which devs concisder to be impossible) but compartmentalization.

It only needs to make sure it's hypervisor is extra-protected, and when VMs get attacked, it only affects one or two programs at a time.

But you'll probably get better compartmentalization by actually running your programs on different machines, though.

RaspberryPi Qubes cluster when?

>>48311

>He's talking about running full OpenBSD in a VM as your main working environment.

No one does this. No one runs a VM just to run a single VM. A VM is a way to colocate processes and isolate them (or run multiple OS's).

>I.e. intruder does not have to attack kernel+hypervisor, he can attack kernel OR hypervisor.

Attacking hypervisior without root sounds hard since only the kernel interacts with hardware. Can't even open raw sockets.

>it's approach to security is not code correctness (which devs concisder to be impossible) but compartmentalization.

Code correctness on linux monstrosity is probably impossible. Never audited either. Isolation is probably good idea.

>It only needs to make sure it's hypervisor is extra-protected, and when VMs get attacked, it only affects one or two programs at a time.

Point of isolating processes into VM's.

>But you'll probably get better compartmentalization by actually running your programs on different machines, though. RaspberryPi Qubes cluster when?

Preferred, but you can't carry around a PI cluster.

I think qubes is a good approach to security for Linux. I think in theory the attack surface has definitely increased when using a hypervisor, but a user level program attacking a hyper-visor sounds hard. Perhaps side channel information leaks are possible (everyone's fear), but has this ever been observed ?

>>48312

>No one runs a VM just to run a single VM.

You'd be surprised how many people run only 1 vm on their rig…

>>48314

>You'd be surprised how many people run only 1 vm on their rig…

Do people really run a hyper-visor just to run 1 VM as their main working environment? Say I want to do all my work in Windows 10. Do I really setup a ESXi server just to install Windows 10 ? If I want to run windows 10, do I install Ubuntu + VirtualBox then not use ubuntu ? It sounds strange to setup your main working environment as a VM as the single VM.

>>48316

Not their main working environment, but usually a one to one ratio, especially macos-win or win-linux when working on cross-platform software or when working with servers.

>>48312

>Attacking hypervisior without root sounds hard since only the kernel interacts with hardware. Can't even open raw sockets.

You remember rowhammer exploit? IIRC there was a working version of it written in javascript.

>>48318

But the main idea is to attack hypervisor not from inside VM but from the outside.

Virtualization and containers for security is like a tourniquet for a snake bite, it will isolate the area, but there is still a chance of the venom leaking through (that gets higher with time), and it doesn't do anything to save the bitten limb. This isn't to say you shouldn't virtualize, but we can't allow virtualization or containers to give us a false sense of security. Just like you wouldn't go fuck with a cobra just because you have a tourniqute, you shouldn't run sketchy/buggy/large and unaudited software just because it's in vm. If you for some reason need to then best practice would be to run it on a seperate machine, preferably with limited/no networking.