zlacker

[parent] [thread] 12 comments
1. fsflov+(OP)[view] [source] 2021-07-20 21:25:44
The only practical security is security through isolation, like what Qubes OS provides. Security through correctness is impossible.
replies(3): >>ttymck+W1 >>Ar-Cur+04 >>api+aj
2. ttymck+W1[view] [source] 2021-07-20 21:37:13
>>fsflov+(OP)
Stupid question: how do you know your isolation is correct?
replies(3): >>fsflov+i5 >>ece+Wa >>pabs3+3z
3. Ar-Cur+04[view] [source] 2021-07-20 21:48:43
>>fsflov+(OP)
You seem to have missed the point of the article completely.

We can’t achieve perfect security (there’s no such thing). What we can achieve is raising the bar for attackers. Simple things like using memory-safe languages for handling untrusted inputs, least-privilege design, defense in depth, etc.

replies(1): >>fsflov+A5
◧◩
4. fsflov+i5[view] [source] [discussion] 2021-07-20 21:58:37
>>ttymck+W1
Not stupid question at all. Nothing is 100% correct. Instead, you look at the attack surface, which for Qubes is extremely small: no network in AdminVM, only 100k lines of code in Xen supervisor, hardware virtualization with extremely low number of discovered escapes and so on.
replies(1): >>snvzz+RH
◧◩
5. fsflov+A5[view] [source] [discussion] 2021-07-20 22:00:35
>>Ar-Cur+04
Memory-safe languages are good, but decreasing the attack surface through compartmentalization is much more reliable I think.
◧◩
6. ece+Wa[view] [source] [discussion] 2021-07-20 22:46:24
>>ttymck+W1
You test for it with rigor and incorporate new learning, just like every other engineering discipline.
7. api+aj[view] [source] 2021-07-21 00:06:10
>>fsflov+(OP)
With Qubes you are depending on the correctness of the VM and whatever hardware it is running on. Modern chips are really complex.

The only perfectly secure computer is one that is off. Security is always about probabilities and trade offs. As you approach perfection cost approaches infinity. It’s similar to adding “nines” to your uptime.

A good security policy balances cost with security and also has plans in place for what to do if security is compromised.

replies(1): >>Tepix+bp1
◧◩
8. pabs3+3z[view] [source] [discussion] 2021-07-21 02:37:42
>>ttymck+W1
There have been Qubes-breaking bugs in Xen before, and it wouldn't be surprising to see more.
◧◩◪
9. snvzz+RH[view] [source] [discussion] 2021-07-21 04:22:24
>>fsflov+i5
Xen is bloated and has a security hole history. This also ignores the size of the Linux acting as dom0, that is.

The only correct answer is formal reasoning, as successfully executed by seL4.

replies(1): >>fsflov+Z11
◧◩◪◨
10. fsflov+Z11[view] [source] [discussion] 2021-07-21 07:54:19
>>snvzz+RH
> Xen is bloated and has a security hole history.

This is a useless security nihilism. Xen is much more secure than anything else in terms of hole history. And Qubes relies on hardware virtualization, not software. Most famous escape from it was discovered by the Qubes founder ("Blue Pill").

The size of Linux in dom0 does not matter, because it has no network, does not run any apps and is only used to manage VMs. There is just no way for an attacker to exploit a bug there.

>formal reasoning

I hope this is the future, but unfortunately it's not the present yet.

replies(1): >>snvzz+eN2
◧◩
11. Tepix+bp1[view] [source] [discussion] 2021-07-21 11:44:28
>>api+aj
More security nihilism.
replies(1): >>api+ZQ1
◧◩◪
12. api+ZQ1[view] [source] [discussion] 2021-07-21 14:26:31
>>Tepix+bp1
I'm not saying security is impossible, just that there are trade offs especially as you try to approach some mythical "perfection."
◧◩◪◨⬒
13. snvzz+eN2[view] [source] [discussion] 2021-07-21 18:44:47
>>fsflov+Z11
>I hope this is the future, but unfortunately it's not the present yet.

Qubes devs are welcome to adopt seL4's VMM virtualization solution.

In seL4's virtualization design, VMM handles VM exceptions, and yet has no more privileges (capabilities, enforced by seL4, which is thoroughly formally proven) than the VM itself, thus an escape from VM to VMM would yield no fruit.

[go to top]