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?
TZubiri 2 days ago [-]
Any attempt to analyze a string that will be executed as a command is a fundamentally unsafe approach, presumably I can make an .sh file and run that and circumvent the mechanism? Off the top of my head. You could say that your analysis will be so deep that it can check the file scripts, it' can do so recursively through bash file chain s of any size, it's so smart in fact it can undecode base64 contents, and even if...
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.
neilv 2 days ago [-]
I bet you're right. This is one kind of thing you need a meticulous programmer to do. But instead, I'd guess most AI-dogfooding engineering organizations in the near future will be taking a vibe-code-it-and-AI-red-team-it approach.
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).
cassianoleal 2 days ago [-]
> not even a container
Genuinely curious, what specific threats are you thinking about when you make this choice?
neilv 2 days ago [-]
Mainly routine software supply chain attacks to unexamined dependencies pulled in by a mess of vibe-coding.
(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.
2 days ago [-]
adi_kurian 2 days ago [-]
Assume the worst.
deadlyllama 2 days ago [-]
Before I read the linked page I assumed this was a rant about using MS Office with files on your local filesystem. Although that would be titled "How Hard is it to Save a File?"
jshmrsn 2 days ago [-]
Am I missing something, or do this article’s purported vulnerabilities rely on an assumption that an attacker already has enough access to your system that the attacker can modify files which your code is referencing by path? Isn’t this more of an escalation vector than a vulnerability in itself?
I’m trying to understand the practical takeaway.
tekacs 2 days ago [-]
It can come up as "I did not expect _arbitrary_ code execution/overwrite, especially not as root."
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)
I'm collapsing and simplifying - lots more possibilities and detail than the above.
dnnddidiej 2 days ago [-]
I am not a sysadmin by a long stretch but I see it as asking another process with more priveledges to do something to a file on your behalf. But I would like sma practical example. Would docker daemon running as root be one?
lapsed_lisper 2 days ago [-]
I've worked on projects with people who've insisted on these approaches, and I've never understood how this secures things in any deep way. As I understand the reasoning, open("/a/b",...) is discouraged in favor of openat(fd, "b", ...) because an attacker might be able to hijack /a. But as I see things, if an attacker has ever been able to hijack what /a contains or what "/a" refers to, they can change whatever "b" ends up naming, and the game is over.
As for the article's glnx_chaseat(), ISTM the 8 orthogonal flag bits are a warning indicator. If there need to be 256 ways to configure pathname resolution semantics, then there are 255 ways the flags compiled into program can be inappropriate for any particular use. Even if we stipulate that there's a problem here that both needs solving, if those flags aren't a hint that this is a flaky solution, I don't know what is.
So it has seemed to me as if the real security problem is the existence of a file system shared among unrelated sets of processes, and that if there is a secure alternative to that on existing operating systems, it probably looks more like embedding program configuration or data inside a program. (But this is handwavy: I'm envisioning stuffing data into ELF or Mach-O segments in signed binaries; some novel mechanism would need to be invented for shebang scripts.) But probably compartmentalizing all systems into distinct VMs is more practical than redesigning all software. (I would imagine that since the article's author works on Flatpak, they are motivated to want something less than VMs to serve as viable compartmentalization solutions, however.)
dnnddidiej 2 days ago [-]
Anyway to open the file with the permissions of the calling process and pass that over?
TZubiri 2 days ago [-]
Knowing what to be concerned about in security is a skill, it is possible to overengineer security and put too much effort in non risks.
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
croemer 2 days ago [-]
Good explanation of the flatpak sandbox escape.
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.”
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:
I'm collapsing and simplifying - lots more possibilities and detail than the above.As for the article's glnx_chaseat(), ISTM the 8 orthogonal flag bits are a warning indicator. If there need to be 256 ways to configure pathname resolution semantics, then there are 255 ways the flags compiled into program can be inappropriate for any particular use. Even if we stipulate that there's a problem here that both needs solving, if those flags aren't a hint that this is a flaky solution, I don't know what is.
So it has seemed to me as if the real security problem is the existence of a file system shared among unrelated sets of processes, and that if there is a secure alternative to that on existing operating systems, it probably looks more like embedding program configuration or data inside a program. (But this is handwavy: I'm envisioning stuffing data into ELF or Mach-O segments in signed binaries; some novel mechanism would need to be invented for shebang scripts.) But probably compartmentalizing all systems into distinct VMs is more practical than redesigning all software. (I would imagine that since the article's author works on Flatpak, they are motivated to want something less than VMs to serve as viable compartmentalization solutions, however.)
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.”