4 ms·

> 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

by 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).
  - lmm 10y ago
    Hah, pledge is an example I was thinking of. I think it's too ad-hoc to deliver real security; I think it's more of an exploit-mitigation technology (comparable to something like ASLR), and as such ultimately a dead end.
    - btrask 10y ago
      I think it's worth distinguishing two problems with pledge: 1. It's likely to have bugs because it's mixed with a constantly changing kernel and can't be proven correct 2. It isn't fine-grained enough If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations.
      - lmm 10y ago
        > If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations. I think the idea that you can allow a program to get itself in an attacker-controlled state and that will be ok as long as you blacklist what the program can do is fundamentally unworkable. So yes, I think pledge-like approaches are always going to be worthless in the long term - if the program is under the attacker's control, it will almost certainly have enough access to be able to do damage (with a sufficiently skilled attacker), because every program does something, particularly if we're talking about a large and complicated program like a browser. (You could potentially segregate the browser into multiple processes with distinct responsibilities, but I'm not convinced that helps, because those processes still have to send commands to each other and so an attacker who can subvert one can probably control the others). If it had the level of granularity to express restrictions like "should be able to write only files that the local user has chosen via the save dialogue" then it might become an effective security layer, but at that point we're not really talking about a sandbox any more.
        10y ago

by btrask 10y ago

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).
- lmm 10y ago
  Hah, pledge is an example I was thinking of. I think it's too ad-hoc to deliver real security; I think it's more of an exploit-mitigation technology (comparable to something like ASLR), and as such ultimately a dead end.
  - btrask 10y ago
    I think it's worth distinguishing two problems with pledge: 1. It's likely to have bugs because it's mixed with a constantly changing kernel and can't be proven correct 2. It isn't fine-grained enough If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations.
    - lmm 10y ago
      > If pledge were completely bulletproof, but still limited in terms of what it could restrict, would that still be worthless? Granularity is an interesting problem but it's more subtle than typical criticisms of ad-hoc mitigations. I think the idea that you can allow a program to get itself in an attacker-controlled state and that will be ok as long as you blacklist what the program can do is fundamentally unworkable. So yes, I think pledge-like approaches are always going to be worthless in the long term - if the program is under the attacker's control, it will almost certainly have enough access to be able to do damage (with a sufficiently skilled attacker), because every program does something, particularly if we're talking about a large and complicated program like a browser. (You could potentially segregate the browser into multiple processes with distinct responsibilities, but I'm not convinced that helps, because those processes still have to send commands to each other and so an attacker who can subvert one can probably control the others). If it had the level of granularity to express restrictions like "should be able to write only files that the local user has chosen via the save dialogue" then it might become an effective security layer, but at that point we're not really talking about a sandbox any more.
      - 10y ago