3 ms·

> What kind of threat model requires someone to use Qubes? "Not trusting modern software to be correct nor secure" is sufficient. I do almost all my web brows

by Syonyk 3y ago

> What kind of threat model requires someone to use Qubes? "Not trusting modern software to be correct nor secure" is sufficient. I do almost all my web browsing in disposable VMs with no access to interesting things like my password manager, email, SSH keys, etc. I also run JITless (disable Javascript JIT engine), because those are a common attack point on browsers. If you compromise my browser from a random site, you get nothing of interest. Even if you pop the kernel. You still have to get through Xen to get to anything I consider of value.

aborsy 3y ago
Browsers have built-in sandboxes, plus sometimes wrapped around stuff like snap.
- Syonyk 3y ago
  And yet... Browser exploits are a thing, and reliably compromise systems. Apple just released a security update yesterday for "something in WebKit," and we see regular browser security updates. The art of escaping browser sandboxes seems to exceed the art of building browser sandboxes. The Javascript JIT engine gains you a lot of attack surface, unfortunately (one of the reasons I run JITless with Javascript). As for snaps, they're just containers - kernel separated. Unfortunately, I consider the value of that against actively malicious code to be "about zero" - local root/kernel exploits are fairly cheap. Containers (so snaps) are great for convenience - if you want to run code you trust without worrying about dependencies, this is fine. They're not fine if you want to isolate things you don't trust - such as a browser from "everything else." Qubes gives you a much harder boundary around your VMs than containers and sandboxes do.
  - aborsy 3y ago
    Snap uses AppArmor, while flatpak uses bubblewrap. You need to have a zero day in these sandboxes, in addition to in the browser. Not so easy! But definitely VMs provide a much better boundary.
snvzz 3y ago
>You still have to get through Xen to get to anything I consider of value. It's not unthinkable, as Xen is huge, at hundreds of kLoCs. But there's an effort[0] to make a Qubes that uses seL4 in place of Xen. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
- fsflover 3y ago
  Most of Xen's vulnerabilities do not affect Qubes OS: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.
  - snvzz 3y ago
    Most vulnerabilities of anything do not affect all its users. But it's bad enough if any do. (some do affect Qubes) It is an architectural problem. SeL4 is a good replacement, with excellent performance and strong formal proofs.
    - fsflover 3y ago
      SeL4 is great an all, but no one of those Xen vulnerabilities has led to an escape since forever, have they?

by Syonyk 3y ago

aborsy 3y ago

Browsers have built-in sandboxes, plus sometimes wrapped around stuff like snap.

Syonyk 3y ago
And yet... Browser exploits are a thing, and reliably compromise systems. Apple just released a security update yesterday for "something in WebKit," and we see regular browser security updates. The art of escaping browser sandboxes seems to exceed the art of building browser sandboxes. The Javascript JIT engine gains you a lot of attack surface, unfortunately (one of the reasons I run JITless with Javascript). As for snaps, they're just containers - kernel separated. Unfortunately, I consider the value of that against actively malicious code to be "about zero" - local root/kernel exploits are fairly cheap. Containers (so snaps) are great for convenience - if you want to run code you trust without worrying about dependencies, this is fine. They're not fine if you want to isolate things you don't trust - such as a browser from "everything else." Qubes gives you a much harder boundary around your VMs than containers and sandboxes do.
- aborsy 3y ago
  Snap uses AppArmor, while flatpak uses bubblewrap. You need to have a zero day in these sandboxes, in addition to in the browser. Not so easy! But definitely VMs provide a much better boundary.

snvzz 3y ago

>You still have to get through Xen to get to anything I consider of value. It's not unthinkable, as Xen is huge, at hundreds of kLoCs. But there's an effort[0] to make a Qubes that uses seL4 in place of Xen. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea

fsflover 3y ago
Most of Xen's vulnerabilities do not affect Qubes OS: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.
- snvzz 3y ago
  Most vulnerabilities of anything do not affect all its users. But it's bad enough if any do. (some do affect Qubes) It is an architectural problem. SeL4 is a good replacement, with excellent performance and strong formal proofs.
  - fsflover 3y ago
    SeL4 is great an all, but no one of those Xen vulnerabilities has led to an escape since forever, have they?