I’m not familiar with this, but what does “solved” mean in this case? Guaranteed inability to compromise systems?
It's my belief that we can have general purpose, easy to use, secure computing for everyone.
No UAC crap, or horrible systems like AppArmor, no virus scanners, etc... just computers that do what you want, and only what you want.
We could have had it decades ago, if things had happened in a slightly different sequence order, related to the flood of personal computers.
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)
The dom0 has no network and doesn't manage, e.g., USB devices.
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.
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)
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.
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).
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.
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?
A capabilities based system could emulate that, and then only let the program access files you allow it any time you use the system's "powerbox" which replaces the open/close file dialogs.
From the users, and the programmers, perspective, it works the same. But if the program has a bug, or virus, or anything else, it won't get access to anything except what you allowed.
We can have easy to use, actually secure, computing for everyone.
And hardware glitches are a thing (edit: and supply chain attacks).
But I do agree that verified correct software can offer very strong guarantees that go well beyond those of commonly deployed software. We could have been in a much better place today.
But there's much synergy there. Each enhances the other.
still not immune to be hacked ofc. I think the last step would be making it common place again to build these things custom. that way they'd have to have more specific information available as threat actors to exploit you. It'd be harder to have generic methods affecting millions of systems.
regardless there are no silverbullets, and tradecraft/opsec will always be a thing. most compromises are because people hand out keys unwittingly rather than 0days and crazy sploits. (they do happen though, but its more expensive than fishing and just loggin on under some dudes credentials)
there are some BSD spinoffs like 5BSD which might end up with a good capability model but even there things like capsicum have their limits and IOMMU based isolation is still a dream. (because entire OS kernel is in one privilege level, accessible as root user, so DMA capable devices kill a lot of those securities).
(my os puts every subsystem, service, device driver, app etc. in their own hardware VM, likely there will be IPC bugs or hypercall bugs still tho in that case)
Nowadays with AI its getting more to a point where people can actually build these systems for themselves. Maybe that is a bigger threat to these big corporate tech companies than some security things. It will allow nations and companies to detach from their Tech...