3 ms·

The whole point of a sandbox is that it's only got toys in it so you don't care when the cat shits in it. But, of course, if the sandbox only contains toys, it'

The whole point of a sandbox is that it's only got toys in it so you don't care when the cat shits in it. But, of course, if the sandbox only contains toys, it's not very useful. You can't sit in it and order a pizza if all you've got is a toy phone. So you leave your wallet, phone, and other critical devices in there. But now it has ceased to be a worry-free safe play space. It's no longer acceptable for the cat to shit in it. This is a fundamental tension and we'll probably keep rediscovering this security problem any time a new container model is developed.

dane-pgp 6y ago
Also known as the Sandboxing Cycle: https://xkcd.com/2044/ https://xkcd.com/2044/
- ineedasername 6y ago
  Yep, this about sums it up: "All I want is a secure system where it's easy to do anything I want. Is that so much to ask?"
Veedrac 6y ago
The point of a sandbox is that the only things in it are the things you've put in it. A can only touch B through mechanisms interfaces it has been gifted. Computer architecture is too broken to provide this guarantee to anything in the same address space, and operating systems are too broken to provide this guarantee through the majority of their interfaces. Proper, pervasive sandboxing in the architecture, ideally down to the function-level, would solve a huge fraction of security bugs, largely for free. Nobody would have had to invent Rust, because that 70% of memory safety bugs would have been almost entirely impossible to exploit from the start. I mean, it's pretty obvious the tension here is largely imaginary when you consider how much random code browsers run from untrusted sources, day after day, and most of those times they fail are because the architecture and OS and language haven't got sensible de-facto sandboxes (again, see that 70% number). For sure, you need to be careful what you give access to who, but the problem is insufficient sandboxing, and the solution is more sandboxing.
waihtis 6y ago
This is a problem I work on, but from a different angle. Run a company that does security sandboxes of a type that you can deploy internally to see what kind of attacks are happening and potentially collect useful telemetry out of the attacker actions. Users definitely want all the telemetry they can get, but also want to completely negate any risk of "accidental bad stuff happening." It's a tricky-to-balance equation, but also a fun and challenging problem to work on.

dane-pgp 6y ago

Also known as the Sandboxing Cycle: https://xkcd.com/2044/ https://xkcd.com/2044/

ineedasername 6y ago
Yep, this about sums it up: "All I want is a secure system where it's easy to do anything I want. Is that so much to ask?"

Veedrac 6y ago

The point of a sandbox is that the only things in it are the things you've put in it. A can only touch B through mechanisms interfaces it has been gifted. Computer architecture is too broken to provide this guarantee to anything in the same address space, and operating systems are too broken to provide this guarantee through the majority of their interfaces. Proper, pervasive sandboxing in the architecture, ideally down to the function-level, would solve a huge fraction of security bugs, largely for free. Nobody would have had to invent Rust, because that 70% of memory safety bugs would have been almost entirely impossible to exploit from the start. I mean, it's pretty obvious the tension here is largely imaginary when you consider how much random code browsers run from untrusted sources, day after day, and most of those times they fail are because the architecture and OS and language haven't got sensible de-facto sandboxes (again, see that 70% number). For sure, you need to be careful what you give access to who, but the problem is insufficient sandboxing, and the solution is more sandboxing.

waihtis 6y ago

This is a problem I work on, but from a different angle. Run a company that does security sandboxes of a type that you can deploy internally to see what kind of attacks are happening and potentially collect useful telemetry out of the attacker actions. Users definitely want all the telemetry they can get, but also want to completely negate any risk of "accidental bad stuff happening." It's a tricky-to-balance equation, but also a fun and challenging problem to work on.