4 ms·

Thanks for this comment. It's the first really substantiative response to my core thesis. I don't think the math is on your side. As the defect rate approaches

by btrask 10y ago

Thanks for this comment. It's the first really substantiative response to my core thesis. I don't think the math is on your side. As the defect rate approaches zero, there are diminishing returns to pushing it lower. On the other hand, the attack surface effect becomes overwhelming. Addressing both at once will be far more effective than concentrating on one or the other. You might be right that in the long run, the defect rate needs to be 0.0. But that is a long ways away. Once we've picked the low-hanging fruit (including perhaps a provably correct sandbox), then we can start thinking about how to prove the correctness of random applications.

lmm 10y ago
> I don't think the math is on your side. As the defect rate approaches zero, there are diminishing returns to pushing it lower. On the other hand, the attack surface effect becomes overwhelming. Addressing both at once will be far more effective than concentrating on one or the other. Huh? That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down. > Once we've picked the low-hanging fruit (including perhaps a provably correct sandbox), then we can start thinking about how to prove the correctness of random applications. "low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right? My view is that there's limited value in lowering the rate of security flaws in ways that aren't on the path to bringing it to zero. Getting it to zero will be valuable; halving it isn't really (there's some economic value in reducing the frequency of breaches, but not enough). So I don't think ad-hoc countermeasures are worthwhile. To the extent to which a sandbox can be written in a principled/provable way it will be valuable. I'm not at all convinced that a general-purpose sandbox is possible, but that's a different question. (The techniques of factoring a program into pieces with the minimal capabilities that they need are valuable, but I think this needs to be done far more holistically than is possible with a sandbox; the security design needs to reflect the program design, because whether particular operations are safe or not is a function of the application-specific context. But this is very much speculation on my part)
- btrask 10y ago
  > That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down. I guess I see 0 as the asymptote. Like if you're already at 99.99% reliability, adding another 9 is quite hard. On the other hand, if you're at 10%, then there are big gains to be had. > "low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right? I think sandboxes generalize much better than application-specific proofs. Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way.
  - lmm 10y ago
    > Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way. What would a generic sandbox enforce? That an application never accesses the network? That it never accesses the local filesystem? That it never communicates with another process? Browsers need to do all those things and more. I think you need application-specific knowledge to be able to enforce the restrictions that matter.
    - btrask 10y ago
      Yes, that is a good question. I think OpenBSD's pledge(2) is a good model for what a simple and useful privilege interface can enforce (although there is room for improvement). To some extent, this is a question of what the requirements are. If a sandbox limits a browser to accessing certain files (a la chroot), is that secure? Or does it need to be more fine grained? This isn't something that can be proven, it's mostly a matter of user interface design. I think there are good arguments for keeping security requirements relatively simple and coarse (including ease of implementation and making sure users can understand what guarantees are offered).

by btrask 10y ago

lmm 10y ago

> I don't think the math is on your side. As the defect rate approaches zero, there are diminishing returns to pushing it lower. On the other hand, the attack surface effect becomes overwhelming. Addressing both at once will be far more effective than concentrating on one or the other. Huh? That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down. > Once we've picked the low-hanging fruit (including perhaps a provably correct sandbox), then we can start thinking about how to prove the correctness of random applications. "low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right? My view is that there's limited value in lowering the rate of security flaws in ways that aren't on the path to bringing it to zero. Getting it to zero will be valuable; halving it isn't really (there's some economic value in reducing the frequency of breaches, but not enough). So I don't think ad-hoc countermeasures are worthwhile. To the extent to which a sandbox can be written in a principled/provable way it will be valuable. I'm not at all convinced that a general-purpose sandbox is possible, but that's a different question. (The techniques of factoring a program into pieces with the minimal capabilities that they need are valuable, but I think this needs to be done far more holistically than is possible with a sandbox; the security design needs to reflect the program design, because whether particular operations are safe or not is a function of the application-specific context. But this is very much speculation on my part)

btrask 10y ago
> That's not how it works, is it? If we want to minimize X * Y and we currently have X = 50 and Y = 5, it's much more efficient to focus on bringing Y down. I guess I see 0 as the asymptote. Like if you're already at 99.99% reliability, adding another 9 is quite hard. On the other hand, if you're at 10%, then there are big gains to be had. > "low-hanging fruit" tends to mean doing unprincipled things that can't be generalized / don't contribute anything in the long term, right? I think sandboxes generalize much better than application-specific proofs. Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way.
- lmm 10y ago
  > Once you have a provably correct sandbox (which I think is possible today, if you exclude things like 3D acceleration), you can run whatever you want in it: old software, games, Flash, Windows 98. Application-specific proofs only work for applications written in the approved way. What would a generic sandbox enforce? That an application never accesses the network? That it never accesses the local filesystem? That it never communicates with another process? Browsers need to do all those things and more. I think you need application-specific knowledge to be able to enforce the restrictions that matter.
  - btrask 10y ago
    Yes, that is a good question. I think OpenBSD's pledge(2) is a good model for what a simple and useful privilege interface can enforce (although there is room for improvement). To some extent, this is a question of what the requirements are. If a sandbox limits a browser to accessing certain files (a la chroot), is that secure? Or does it need to be more fine grained? This isn't something that can be proven, it's mostly a matter of user interface design. I think there are good arguments for keeping security requirements relatively simple and coarse (including ease of implementation and making sure users can understand what guarantees are offered).