Comment by zahlman
1 day ago
> The only way for a tool to escape a sandbox is if you built a crappy sandbox
Well, sure, but typical software-level sandboxes are crappy at an alarmingly high rate, either on this access or the usability access. Languages like Python are fundamentally not designed for sandboxed interpretation; any Bash tool is at least as insecure as all of the vulnerabilities in all whitelisted executables.
I'm arguing for hardware-level measures on basic defense-in-depth principles. Like, such a huge part of the reason why we're even doing this AI research is to find vulnerabilities, so it's insane to have a test environment that doesn't start from the premise that there are vulnerabilities. In everything.
Well:
1. Park your Python or whatever code inside a VM with no connectivity to anything (other than to accept inbound ssh) and with a canned set of PyPi etc packages available for it to use
2. Park hypervisor for that in a machine with no connectivity except thru a firewall that only admits the relevant ssh traffic.
3. Make sure to use ssh clients that can’t be exploited by a remote server. If this is too challenging, then use telnet or rlogin instead.
4. You can extend this to eg allow outbound calls to an LLM. Alternatively, place the GPU hardware and LLM weights inside the hypervisor machine.
Congratulations, now nothing can escape except what you allow to from the output from rsh.