[saidnooneever]

most people dont do a lot on their machines. they have specific tasks they want to do. The idea is to isolate by default and crack open gaps by policy. You can still do 'anything' but you wouldnt want to enable 'anything' to be possible in the policy..

[fsflover]

Sounds like security through compartmentalization is more user-friendly: You can run whatever you want and how you want it in a dedicated VM, keeping sensitive things safely isolated, without much thinking of what to enable. Case in point: Qubes OS, my daily driver. Btw it already exists and is stable.

[ethbr1]

> security through compartmentalization is more user-friendly: You can run whatever you want and how you want it in a dedicated VM, keeping sensitive things safely isolated

My brain hurts. How is a system where you can run whatever you want, however you want, but still keep sensitive things safely isolated possible?

Either you have restrictions on what you can run or access (in which case those limit sandboxed capabilities) or you have a hypothetically secure system, the security features of which you never leverage (because sandboxes have absolute freedom).

Unless you were talking about the ability to guarantee a monitor-only hypervisor or resource slice a machine into multiple tenants? (i.e. no/light touch hypervisor situations)

[saidnooneever]

this relys wholly on user skill which most people will not be able to do. you need extreme tradecraft and opsec to keep really secure. any little mistaken copy between domains etc. might compromise.

This is the downside of isolation machines and their upside.

Hard to make a completely isolated machine for all workflows and keep all data at all times inaccessible for exploits. But because each user has their own ways its more potential that 'your particular way of breaking the model' is not known or exploitable (yet).

A lot of holes you open are one-time actions from within a restricted domain.

in qubes you have cross domains tools from domain0 for this, which is very hard to reach (but not impossible).

And then supplychain is also hard. Qubes have canaries, but i think most ISO people copy into their dom0 and spinnVMs off of are not doing such rigorous things. (depends what u use ofc).

[fsflover]

> this relys wholly on user skill which most people will not be able to do. you need extreme tradecraft and opsec to keep really secure.

This depends on the chosen level of compartmentalization. For most people, it might be sufficient to store passwords in a dedicated, offline VM and do everything else in another one. This will already be huge improvement.

[fsflover]

I'm not sure I understand your question. VMs run full operating systems on top of Xen hypervisor relying on hardware-assisted virtualization (VT-d or similar). You can run untrusted software in a dedicated VM and keep your sensitive data in another offline VM.

The dom0 has no network and doesn't manage, e.g., USB devices.

[ethbr1]

You can't have full general purpose computing on a system and perfect isolation for free.

By definition, the latter implies limits on the former.

Either you have complete freedom to run whatever you want, however you want, or you enforce limits to guarantee system behavior and enforce isolation.

And if you do the latter... then you don't have the former.

[fsflover]

Can you elaborate? I'm not a computer scientists. In my understanding, full VMs are practically equivalent to general purpose computers. What are their limitations? Malware escapes?

Last VM escape in VT-d was discovered in 2006 by the Qubes founder, so I really feel safe on Qubes, https://en.wikipedia.org/wiki/Blue_Pill_(software)

[ethbr1]

We're talking about apples and oranges.

I thought your original point above was that VMs freed you from having to come up with policy-based isolation rules (which have always been a UX weakness of policy-based isolation systems).

The point I was making is that VMs don't provide any security guarantees unless you also use the trusted hypervisor layer to enforce something.

At lightest touch, this might be time-slicing resources and ensuring they're evenly split between VMs, regardless of what individual VMs try to do.

But to provide policy-alike granular security control on VMs, you fundamentally have to generate similar rules. E.g. network can only be used by this VM in this way, etc.

Which gets you right back to having to define policies.

From an architecture security perspective, sure, having a trusted hypervisor enforcing the rules is nice. But it doesn't fundamentally fix the problem of getting policies right... if you're trying to guarantee the same level of control.

[saidnooneever]

QubesOS is not bad indeed. its not perfect (they are looking i think to replace Xen or make it much more thin layer). Its definitely the way i think if u want to retain compatibility with existing OSes/tools.

[fsflover]

They are not looking to replace Xen. They plan to add support of KVM without breaking Xen: https://github.com/QubesOS/qubes-issues/issues/7051#issuecom...

They also plan to replace Fedora in dom0 with something minimized https://github.com/QubesOS/qubes-issues/issues/1919#issuecom.... Is this a problem for you?