Why is that ridiculous? Certainly it’s not the sole answer to the problem on its own, but if I were to use (say) a string manipulation library, why should it have access to my filesystem and the internet?
You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. And it doesn't even guarantee that the code doesn't do other bad things that the sandbox doesn't deny. Sandboxing has comprehensively failed as a security measure for browser extensions - hence both Chrome and Firefox retreating from extensions.
Or, as a spurious example: you could audit the library's code to make sure it's not doing bad things, and then copy/paste it into your code base. You could even just copy the bits you need and leave the bits that deal with use cases that you don't need. Easier, simpler, more efficient and less dangerous.
>You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities.
I'm going to dispute this. Yes, if your sandbox takes a ton of memory to isolate some piece of code, scaling that up to confine each module individually isn't going to be workable. But who says a sandbox has to be heavyweight?
Our current systems (UNIX-likes, etc) provide a ton of ambient authority to each process; given that, it takes a lot of effort to e.g. intercept syscalls and decide whether or not the application should have access to them. That's an artifact of design decisions from decades ago, though; let's say we were starting from scratch, why give every process access to all those syscalls to begin with? If you want an example of how a system could be designed from the start without that authority, take a look at this paper: http://mumble.net/~jar/pubs/secureos/secureos.html
There's a difference between compiled binary and uncompiled code. I guess if you're working in an interpreted language that never gets compiled, like Python, you might not notice the difference so much. But even then, this is not using an API for a separate service that exists on a different server. This is something that happens in your process.
> ...processes...
If your string processing library has to live in a separate process in order to sandbox it, then yes, you are creating more problems than you're solving.
You're going to have to segment your whole application into chunks, each chunk being sandboxed away from the others, causing huge overheads and complications. It'll generate more complexity, more errors, more security vulnerabilities. And it doesn't even guarantee that the code doesn't do other bad things that the sandbox doesn't deny. Sandboxing has comprehensively failed as a security measure for browser extensions - hence both Chrome and Firefox retreating from extensions.
Or, as a spurious example: you could audit the library's code to make sure it's not doing bad things, and then copy/paste it into your code base. You could even just copy the bits you need and leave the bits that deal with use cases that you don't need. Easier, simpler, more efficient and less dangerous.