4 ms·

> we should instead isolate every library we import and run it under a sandbox I don't see how that'd be possible. Often we want the library to do useful thing

> we should instead isolate every library we import and run it under a sandbox I don't see how that'd be possible. Often we want the library to do useful things for the application, in the context of the application. What would incentivize developers to specify more fine-grained permissions per library than the union of everything their application requires? I see more use in sandboxing entire applications, and giving them more selective access than "the entire user account" like we do these days. This is maybe more how smartphones operating systems work than desktop computers?

immibis 1y ago
In languages without ambient I/O capabilities, it's not as hard as it sounds if you're used to languages with them. Suppose the only way you can write a file is if I give you a handle to that file - then I know you aren't going to write any other files. Of course, main() receives a handle from the OS to do everything. If I want you to decode a JPEG, I pass you an input stream handle and you return an output memory buffer; because I didn't give you any other capabilities I know you can't do anything else. Apart from looping forever, presumably. It still requires substantial discipline because the easiest way to write anything in this hypothetical language is to pass the do-everything handle to every function. See also the WUFFS project: https://github.com/google/wuffs https://github.com/google/wuffs - where things like I/O simply do not exist in the language, and therefore, any WUFFS library is trustworthy. However, it's not a general-purpose language - it's designed for file format parsers only.
- criemen 1y ago
  Fair enough, it makes more sense in a, say, Haskell-style pure functional language. Instead of getting a general IO monad, you pass in more restricted functionality. Still, it'd be highly painful. Would it be worth the trade-off to prevent supply chain attacks?
  - immibis 1y ago
    It prevents a lot more than just supply-chain attacks. Give the unzipper a subdirectory handle with parent disabled, and it won't be vulnerable to directory traversal attacks, no matter how badly it's written.
  - tome 1y ago
    I developed my Haskell library Bluefin to program in this way, not as a security measure but just as a way to help structure programs in a coherent way (which is one of the benefits of many well typed Haskell libraries). In principle the same idea could be use for high assurance software, but that's not what I'm going for specifically. Anyway, I find writing in this style much more convenient than in any other Haskell style. https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin
  - yencabulator 11mo ago
    No need for pure FP or monads I believe. Consider statically analyzing the library for: 1. `unsafe` 2. import/use of any ambient effects (std::fs::open etc; good enough to have a much smaller allowlist). allow using methods on passed-in &std::fs::File but do not allow std::fs::File::open. beware anything making openat a method on File. Making this realistic may need new API conventions. WASI is doing some of this work already. 3. apply recursively to dependencies Now the library can only operate on the things passed in to it. Much preexisting source won't qualify, but e.g. PNG decoding should.

immibis 1y ago

In languages without ambient I/O capabilities, it's not as hard as it sounds if you're used to languages with them. Suppose the only way you can write a file is if I give you a handle to that file - then I know you aren't going to write any other files. Of course, main() receives a handle from the OS to do everything. If I want you to decode a JPEG, I pass you an input stream handle and you return an output memory buffer; because I didn't give you any other capabilities I know you can't do anything else. Apart from looping forever, presumably. It still requires substantial discipline because the easiest way to write anything in this hypothetical language is to pass the do-everything handle to every function. See also the WUFFS project: https://github.com/google/wuffs https://github.com/google/wuffs - where things like I/O simply do not exist in the language, and therefore, any WUFFS library is trustworthy. However, it's not a general-purpose language - it's designed for file format parsers only.

criemen 1y ago
Fair enough, it makes more sense in a, say, Haskell-style pure functional language. Instead of getting a general IO monad, you pass in more restricted functionality. Still, it'd be highly painful. Would it be worth the trade-off to prevent supply chain attacks?
- immibis 1y ago
  It prevents a lot more than just supply-chain attacks. Give the unzipper a subdirectory handle with parent disabled, and it won't be vulnerable to directory traversal attacks, no matter how badly it's written.
- tome 1y ago
  I developed my Haskell library Bluefin to program in this way, not as a security measure but just as a way to help structure programs in a coherent way (which is one of the benefits of many well typed Haskell libraries). In principle the same idea could be use for high assurance software, but that's not what I'm going for specifically. Anyway, I find writing in this style much more convenient than in any other Haskell style. https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin
- yencabulator 11mo ago
  No need for pure FP or monads I believe. Consider statically analyzing the library for: 1. `unsafe` 2. import/use of any ambient effects (std::fs::open etc; good enough to have a much smaller allowlist). allow using methods on passed-in &std::fs::File but do not allow std::fs::File::open. beware anything making openat a method on File. Making this realistic may need new API conventions. WASI is doing some of this work already. 3. apply recursively to dependencies Now the library can only operate on the things passed in to it. Much preexisting source won't qualify, but e.g. PNG decoding should.