How Hard Is It to Open a File?

▲ How Hard Is It to Open a File?(blog.sebastianwick.net)

51 points by ffin 2 days ago | 9 comments

▲ codethief an hour ago | parent | next [-]

> https://github.com/flatpak/flatpak/security/advisories/GHSA-...

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?

	▲	adi_kurian 11 minutes ago \| parent \| next [-]
		Assume the worst.
	▲	moron4hire 9 minutes ago \| parent \| prev [-]
		This is why I'm building my own agent harnesses at work. I can't escape the bosses asking for AI, but I'm not going to rely on some frothy startup's vibe-coded slop with a pinky promise they Take Security Seriously (just like they say about user privacy) to provide it. An agent harness is not hard to build. It has taken me barely a few hours in between the massive number of meetings I'm subjected to every day. I continue to not be impressed by the stuff people claim they needed AI to build for them. Really haven't seen anything that either A) works, B) is convincingly secure, or C) I couldn't have built out of scraps in a cave.

▲ jshmrsn 2 hours ago | parent | prev | next [-]

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 an hour ago \| parent \| next [-]
		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 an hour ago \| parent \| prev [-]
		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?

▲ dnnddidiej an hour ago | parent | prev | next [-]

Anyway to open the file with the permissions of the calling process and pass that over?

▲ TZubiri 3 hours ago | parent | prev | next [-]

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 3 hours ago | parent | prev [-]

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.”