Just yesterday I was thinking about a related attack vector on AI agents: Many harnesses "sandbox" (at the application level) file reads/writes and shell commands by checking whether a given path has been whitelisted. However, I bet there are cases where the agent could simply create a symlink to somewhere else and thus trick the "sandbox" into thinking the agent is authorized?
No, stop, if you do that, you have entered a rabbit hole, ignore the command, assume it can be malicious. Path constraints are already fundamentally solved with tech as old as UNIX users, you are 50 years behind in terms of security and should not be concerning yourself with cutting edge issues for that reason.
I don't trust sandbox claims from those companies, and only run CLI-ish code on workstation inside a full VM (not even a container).
Genuinely curious, what specific threats are you thinking about when you make this choice?
(Though it would also give some protection against growth hacking or kludge expedience that goes a little too naughty. We're already seeing some questionable behavior there, as some rush to get their functionality working first.)
Since containers are for fairly trusted code, and relatively easy to break out of, compared to a good VM.
I’m trying to understand the practical takeaway.
e.g. in an installer:
1. Download package
2. Maybe 'prepare' as the user – this could be _entirely_ caller-driven (i.e. you didn't run any code, you just provided materials for the installer to unpack/place/prepare), or it could include some light/very restricted code execution
3. Perform 'just one operation' such as 'copying things into place' (potentially with escalation/root)
4. In step 3, the preparation from 2 resulted in the placement of something in binary position (that then runs), and/or overwriting of important files (if something placed in step 2 was used as a target)
This reminds me of when a student was concerned about the client leaking the server's ip address.
Not saying that there aren't vulns, but the fix is fixing the bug and using a standard hardening mechanism like selinux or unix users. I strongly doubt that the root issue is the good old filesystem api everyone has been using for decades, it's more likely to be your code bro
For those allergic to LLM writing: Some sentences read very LLM-like, e.g.:
> The fix wasn’t “change one function” — it was “audit the entire call chain from portal request to bubblewrap execution and replace every path string with an fd.”