Sebastian Wick has a great explanation of why opening files – programmatically – is a lot more complex and fraught with dangers than you might think it is.
It’s a question I had to ask myself multiple times over the last few months. Depending on the context the answer can be:
- very simple, just call the standard library function
- extremely hard, don’t trust anything
If you are an app developer, you’re lucky and it’s almost always the first answer. If you develop something with a security boundary which involves files in any way, the correct answer is very likely the second one.
↫ Sebastian Wick
This issue was relevant for Wick as he is one of the lead developers of Flatpak, for which a number of security issues have recently been discovered, and it just so happens that many of these issues dealt with this very topic. The biggest security issue found was a complete sandbox escape, originating from the fact that flatpak run, the command-line tool to start a Flatpak application, accepted path strings, since flatpak run is assumed to be run by a trusted user. The problem lay in a D-Bus service sandboxed applications could use to create subsandboxes, and this service was built around, you guessed it, flatpak run.
The issues in question, including this complete sandbox escape, have been addressed and fixed, but they highlight exactly the dangers that can come from opening files. This subsandboxing approach in Flatpak is built on assumptions from fifteen years ago, and times have changed since then. If you’re a programmer who deals with opening files, you might want to take a look at your own code to see if similar issues exist.
