4 ms·
Attempting to run untrusted code on trusted hardware is a fool's errand. Sandboxes do not work. Hardware privilege separation does not work. It is a lost cau
by moonchild 5y ago
Attempting to run untrusted code on trusted hardware is a fool's errand. Sandboxes do not work. Hardware privilege separation does not work. It is a lost cause. We need to start separating devices, and stop normalizing js.
- saagarjha 5y agoDon’t you work on a web browser?
- moonchild 5y agoNo.
- fsflover 5y agoYes, it does work: https://qubes-os.org https://qubes-os.org.
- moonchild 5y agoYes, because no one has ever escaped from a VM. Wait ... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=qemu https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=qemu
- fsflover 5y agoThis is not how Qubes VMs work. They use hardware (VT-d) virtualization, which AFAIK was last time broken by the Qubes founder in 2003: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software).
- moonchild 5y agoRowhammer? F00f? Spectre?
- fsflover 5y agoThose are indeed serious problems. But you can't simply say "sandboxes don't work". See also: https://news.ycombinator.com/item?id=27897975 https://news.ycombinator.com/item?id=27897975
- moonchild 5y ago> you can't simply say "sandboxes don't work" Why, though? I find it extremely plausible that there is no sandbox which can prevent programs from escaping, and that the same is not true of physical separation. (Obviously even physically separated machines are prone to problems too; but I believe it is possible to resolve them.) Regarding 'don't be nihilistic', I really don't think that's what I'm doing; I'm suggesting a path forward, a different course of action. It doesn't seem any more nihilistic to say 'let's move away from shared hardware' than to say 'let's move away from md5'.
- fsflover 5y ago> (Obviously even physically separated machines are prone to problems too; but I believe it is possible to resolve them.) It depends on your threat model: https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-using-a-separate-physical-machine https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u.... > I'm suggesting a path forward, a different course of action. It's not a practical path for most people. It's expensive and very cumbersome. You effectively suggest to give up. Good sandboxing is much, much better than physical separation, because it's actually doable. I run Qubes as my daily driver. I can't imagine managing a bunch of machines. Also, Intel ME is disabled and neutralized on my machine, Spectre is patched (and hyper-threading is disabled on Qubes). Such things are also extremely rare.
- moonchild 5y ago> https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-using-a-separate-physical-machine https://www.qubes-os.org/faq/#how-does-qubes-os-compare-to-u... I don't really buy the arguments given there. All but the first of the 'cons' listed regarding physical separation apply equally well to virtual machines. There is a link to a longer paper; I will read it later; perhaps it has more compelling arguments. > expensive Most people are using phones and computers that cost hundreds of dollars. The cheapest raspberry pi is, what, $5? Getting a few of those would not be prohibitive for many people. > very cumbersome That is true, but we can do something about it. How cumbersome was it to habitually run software in vms, before qubes?