[throwaway15908]

Tangetial question: Seen all the recent supply chain attacks, is there a way to defend FOSS projects with something like project defined capabilities for every third party dependency? So eg. you could include a math lib and mask everything regarding filesystem or network, etc? Especially for rust i would like to see a holisitic solution to this growing thread, facing the accelerating trend of central repositories.

[PoignardAzur]

There's currently talks about sandboxing proc macros, install scripts and build scripts.

It would be nowhere near enough to make it safe to download untrusted dependencies, but it would at least stop the most trivial forms of attack.

Sandboxed dependencies with user-specified capabilities are a very, very long way away, if they ever happen.

[miloignis]

On the impl side, WebAssembly was built from the beginning to support that use case, and many languages are adding backend support for it. On the language side, I really like type systems with Algebraic Effects (koka-lang.org has some of the cool research into it).

[cillian64]

This is more plausible for a language with a runtime like Python. But Rust is fundamentally designed to be a systems language where you have full access to everything (and, if you use unsafe, raw access to memory and arbitrary code execution). It’s hard to imagine how you’d add a sandboxing layer to the language, it seems more like something the OS would have to do for you.

[throwaway15908]

On a broad scope, you could solve this at compile time. The source simply does not compile when filesystem or networking crates/builtins are not defined.

If you want to have more fine grained white listing, like only grant access to a certain directory, this could get really messy quick, trying to solve this at compile time.

[oconnor663]

You'd probably have to start by banning unsafe code in general, but then whitelisting/allowlisting specific versions of specific crates that are allowed to use it, so that at least the most popular dependencies don't break.

[mkj]

My rough understanding is that Caja for JavaScript kind of did that. Libraries didn't have access to the whole scope, could only access what they were given via capabilities. https://en.wikipedia.org/wiki/Caja_project

[bawolff]

I feel like that is very hard to make work securely when the boundries are so ill defined. At the end of the day, untrusted code is untrusted. What happens when you use your math library to do some math on a security critical value?

[ATsch]

The Pony language has this concept, but I personally found it mostly a pain to use.

[goodpoint]

You use packages from a well known Linux distribution.

[ratorx]

That doesn’t solve the problem, just moves the chain of trust.

[goodpoint]

Not at all. It creates a chain of trust instead of relying on random unknown github accounts.

When was the last time a major distribution found a backdoor in a popular package?

[estebank]

> When was the last time a major distribution found a backdoor in a popular package?

Packagers not finding a backdoor doesn't mean that there isn't one. How many packagers actively audit the code they support for a given distro? It is not uncommon for distros that support esoteric platforms will claim a given package works for that platform because it compiles, but it reliably segfaults on execution. Who's responsible for that? Packagers have even introduced[1] vulnerabilities by "fixing" code they didn't fully understand at the time.

Packagers have a difficult, thankless task, and we're doing them no favors by being confused at what their job is. They ensure that the package builds, integrates with the rest of the distribution as much as possible and updates/patches swiftly when issues are found upstream.

[1]: https://lwn.net/Articles/282038/

[goodpoint]

> Packagers not finding a backdoor doesn't mean that there isn't one.

Nice stramwan there - when the alternative is trusting random strangers on github.

> How many packagers actively audit the code they support for a given distro?

Many, plus large companies do plenty of vetting and indemnification on popular distros.

There are very large contracts involved in this. Do you think the typical bank installs random stuff from the Internet on their payment processors?

> Packagers have even introduced[1] vulnerabilities by "fixing" code they didn't fully understand at the time.

Another strawman. How many vulnerabilties have been prevented or fixed by packagers? Quite a good number.

> we're doing them no favors by being confused at what their job is.

Speak for yourself.