Posting this here to document what we’ve investigated for fixing this so far, why it didn’t work, and what other options we have.
The first, obvious option, is to just run pcmanfm-qt --daemon-mode at startup so that the file manager just works. This is unfortunately problematic, because sometimes the VMs Whonix-Workstation runs under are very RAM-constrained, and the additional memory PCManFM-Qt takes up is unacceptable.
The second option is to make PCManFM-Qt a D-Bus activated service. This almost works, but unfortunately while PCManFM-Qt can be launched via D-Bus activation, it fails to actually open the requested directory the first time it is launched. This is the issue covered in the links in this post above.
The third option is to create a new lightweight shim that can properly receive requests to open a folder over D-Bus, and launch PCManFM-Qt with the appropriate folders open automatically. This seemed to be the most promising option initially, and I did quite a bit of work developing this shim, but in the process I discovered that if PCManFM-Qt is pointed at a file (i.e. pcmanfm-qt document.odt), it will actually try to open the file similar to xdg-open rather than opening the directory the file is in. This behavior makes it impossible to implement a shim like this without creating a TOCTOU vulnerability that would allow Tor Browser to escape AppArmor confinement:
- The browser, if compromised, could create a directory at
/path/to/dir, and a file at/path/to/malicious.odt. - Then the browser could call
org.freedesktop.FileManager1.ShowFolders('/path/to/dir'), which would call the shim. - The shim would be able to ensure that
/path/to/dirwas actually a directory, and could then callpcmanfm-qt /path/to/dir, but there’s a small-ish window of time between the directory check and PCManFM-Qt actually opening the directory. - The browser could then do the equivalent of
rmdir /path/to/dir; mv /path/to/malicious.odt /path/to/dir;during that short race window. - PCManFM-Qt would launch, and would proceed to open
/path/to/dir, which would actually launch LibreOffice withmalicious.odtopen. At that point, the document could exploit bugs in LibreOffice, or possibly use macros to run arbitrary code, or whatever. (Note that LibreOffice is only an example here; there are many different file types that could be used in a similar way, and depending on the applications the user has installed it may be possible to use this technique to run a script in an interpreter.)
The fact that PCManFM-Qt actually opens files it is pointed at is very surprising to me, and I would argue is even wrong behavior, but it’s the behavior we have to work with. The shim idea is therefore non-viable.
There are still a few options left that might work:
- We could switch back to Thunar as our file manager. That would mean we’d have to maintain two file managers, so this is non-ideal.
- We could adjust the
torbrowserscript intb-launcherto runpcmanfm-qt --daemon-mode &before starting Tor Browser. This would be hacky, but would fix things for Tor Browser specifically. Applications like Signal could still have problems. - We could autostart PCManFM-Qt in daemon mode, but only if “enough” RAM is detected (where “enough” is a sane default like 2 GB, and can be adjusted by the user via some configuration file).
@marmarek Any thoughts on the above? I personally like the last solution (autostart in daemon mode but only when RAM is sufficient to allow it), does that seem like it would work?