4 ms·

Every modern browser uses sandboxing to avoid having a "trivial software bug allow the author of a web page to upload and run code in your browser process." Yo

by cmccabe 13y ago

Every modern browser uses sandboxing to avoid having a "trivial software bug allow the author of a web page to upload and run code in your browser process." You simply run the potentially insecure code in a separate, unprivileged process. Apple has a special set of sandbox APIs that make it easy for applications to irrevocably give up privileges such as the ability to write to the file system, etc. It's not as easy on Linux and Windows, but it is possible. SGX really exists for one reason, and one reason only-- it's another attempt to implement some kind of un-bypassable DRM. Joanna points this out in her writeup. All of the other so-called advantages you can already get simply by running a VM. Get ready to jailbreak your PC I guess. I can just feel the security oozing from my pores.

tptacek 13y ago
Has a year gone by since they were introduced where some kind of sandbox jailbreak hasn't been published? And: it cost Google many hundreds of thousands of dollars to engineer the sandbox system it has, just as it cost Adobe huge amounts of money to retrofit sandboxes onto PDF. How well sandboxed is nginx? Answer: not at all. Also, you understand that any VM system that grants the security capability you're talking about also grants content software the ability to protect content, right? They're two sides of the exact same coin. You don't see that they are, because the "security" sign of the coin implicitly but subtly presupposes hostile code is running on the machine already, where the "DRM" side of the coin obviously hosts adversarial code, because that adversarial code is the "protagonist" of its story.
- cmccabe 13y ago
  A lot of the Chrome jailbreaks were done through attacking the embedded Flash player, which wasn't sandboxed at the time. How well sandboxed is nginx? Answer: not at all. Actually, that's not the answer. ngnix is sandboxed by using selinux, using a chroot jail, using AppArmor, or any one of a number of different ways. How many years have gone by without a Java or web-based exploit being announced? 0. Maybe you should not throw stones, when your own house is made of glass. Security and DRM are not two sides of the same coin. There are lots of insecure systems that aren't DRMed. And there are lots of ultra-secure OSes, like OpenBSD, that don't include DRM. I'm not a tinfoil-hat type of person, but I have a healthy fear of code written by firmware engineers. That's why things like EFI and now this are terrible. They're basically shovelware that you can't get rid of on your PC. Like the uninstallable android apps, but 100x worse.
vidarh 13y ago
> All of the other so-called advantages you can already get simply by running a VM. Only when you trust the hardware, and hypervisor. There's a huge potential set of advantages here for cloud platforms where people running various VMs do not trust the other tenants, and might not want to have to fully trust the hosting provider. The possibility of having everything encrypted in memory and encrypted on disk, and with other code running on the same CPU unable to peek at what you're computing might not be foolproof (e.g. you'd have to trust that the provider does not run a CPU that's somehow backdoored), but it would still be a substantial improvement compared to what we have now. It means that a large class of security flaws in the hypervisors would still be unable to expose client VMs, for example. I do agree with you that un-bypassable DRM is probably part of the motivation, but there are plenty of other uses.

by cmccabe 13y ago

tptacek 13y ago

Has a year gone by since they were introduced where some kind of sandbox jailbreak hasn't been published? And: it cost Google many hundreds of thousands of dollars to engineer the sandbox system it has, just as it cost Adobe huge amounts of money to retrofit sandboxes onto PDF. How well sandboxed is nginx? Answer: not at all. Also, you understand that any VM system that grants the security capability you're talking about also grants content software the ability to protect content, right? They're two sides of the exact same coin. You don't see that they are, because the "security" sign of the coin implicitly but subtly presupposes hostile code is running on the machine already, where the "DRM" side of the coin obviously hosts adversarial code, because that adversarial code is the "protagonist" of its story.

cmccabe 13y ago
A lot of the Chrome jailbreaks were done through attacking the embedded Flash player, which wasn't sandboxed at the time. How well sandboxed is nginx? Answer: not at all. Actually, that's not the answer. ngnix is sandboxed by using selinux, using a chroot jail, using AppArmor, or any one of a number of different ways. How many years have gone by without a Java or web-based exploit being announced? 0. Maybe you should not throw stones, when your own house is made of glass. Security and DRM are not two sides of the same coin. There are lots of insecure systems that aren't DRMed. And there are lots of ultra-secure OSes, like OpenBSD, that don't include DRM. I'm not a tinfoil-hat type of person, but I have a healthy fear of code written by firmware engineers. That's why things like EFI and now this are terrible. They're basically shovelware that you can't get rid of on your PC. Like the uninstallable android apps, but 100x worse.

vidarh 13y ago

> All of the other so-called advantages you can already get simply by running a VM. Only when you trust the hardware, and hypervisor. There's a huge potential set of advantages here for cloud platforms where people running various VMs do not trust the other tenants, and might not want to have to fully trust the hosting provider. The possibility of having everything encrypted in memory and encrypted on disk, and with other code running on the same CPU unable to peek at what you're computing might not be foolproof (e.g. you'd have to trust that the provider does not run a CPU that's somehow backdoored), but it would still be a substantial improvement compared to what we have now. It means that a large class of security flaws in the hypervisors would still be unable to expose client VMs, for example. I do agree with you that un-bypassable DRM is probably part of the motivation, but there are plenty of other uses.