undefined | Better HN

0 pointsuyzstvqs1d ago0 comments

That's no solution. If you can't trust and/or verify dependencies, and they are malicious, then you have bigger problems than what a sandbox will protect against. Even if it's sandboxed and your host machine is safe, you're presumably still going to use that malicious code in production.

0 comments

nazcan1d ago

I'm supportive of going further - like restricting what a library is able to do. e.g. if you are using some library to compute a hash, it should not make network calls. Without sub-processes, it would require OS support.

azornathogron18h ago

In type system theory I think what you're looking for is "effect systems".

You make the type system statically encode categories of side-effects, so you can tell from the type of a function whether it is pure computation, or if not what other things it might do. Exactly what categories of side-effect are visible this way depends on the type system; some are more expressive than others.

But it means when you use a hash function you can know that it's, eg, only reading memory you gave it access to and doing some pure computation on it.

fn-mote1d ago

Which exists: pledge in OpenBSD.

Making this work on a per-library level … seems a lot harder. The cost for being very paranoid is a lot of processes right now.

lanstin1d ago

It's a language/compiler/function call stack feature, not existing as far as I know, but it would be awesome - the caller of a function would specify what resources/syscalls could be made, and anything down the chain would be thusly restricted. The library could try to do its phone home stats and it would fail. Couldn't be C or a C type language runtime, or anything that can call to assembly of course. @compute_only decorator. Maybe could be implemented as a sys-call for a thread - thread_capability_remove(F_NETWORK + F_DISK)? Wouldn't be able to schedule any work on any thread in that case, but Go could have pools of threads for coroutines with varying capabilities. Something to put the developer back in charge of the mountain of dependencies we are all forced to manage now.

staticassertion1d ago

That's exactly what a sandbox is designed for. I think you're overly constraining your view of what sort of sandboxing can exist. You can, for example, sandbox code such that it can't do anything but read/write to a specific segment of memory.

exyi1d ago

Except that LiteLLM probably got pwned because they used Trivy in CI. If Trivy ran in a proper sandbox, the compromised job could not publish a compromised package.

(Yes, they should better configure which CI job has which permissions, but this should be the default or it won't always happen)

j / k navigate · click thread line to collapse