Hacker News Reader

Comment by criemen | Hacker News Reader

> 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?

View on HN

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 - 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.

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?

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.

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

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.

Reply on news.ycombinator.com