Firefox and KeePassXC Flatpaks
Flatpaks are amazing and all that. But application sandboxing, so an application cannot do anything it wants, is a challenge - even more so when you have two applications that need to talk to each other. Perhaps it shouldn’t come as a surprise that native-messaging sandboxing support for Flatpak has been in development for over a year. To celebrate its anniversary I thought I’d write down how to drill a native-messaging sized hole into the sandbox. This enables the use of native messaging even without portal integration, albeit also without sane degrees of sandboxing.
First off, please understand that this undermines the sandbox on a fairly fundamental level. So, don’t do this if you don’t keep your Firefox updated or visit particularly dodgy websites.
For the purposes of this post I’m assuming Firefox and KeePassXC are installed as Flatpaks in user scope.
First order of business is setting up KeePassXC so it writes its definition file in a place where Firefox can read it. Fortunately it has a setting for this:
~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/ is the path inside Firefox’ home where the defintion file will be written. Naturally we’ll also need to adjust the Flatpak permissions so KeePassXC can write to this path.
flatpak override --user --filesystem=~/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts org.keepassxc.KeePassXC
At this point Firefox knows about the native messaging host but it won’t be able to run it. Alas. We need some rigging here. The problem is that Firefox can’t simply flatpak run the native messaging host, it needs to spawn a host process (i.e. a process outside its sandbox) to then run the KeePassXC Flatpak and that then runs the NMH.
Fortunately the NMH definition files are fairly straight forward:
{"allowed\_extensions":\["keepassxc-browser@keepassxc.org"\],
"description":"KeePassXC integration with native messaging support",
"name":"org.keepassxc.keepassxc\_browser",
"path":"/home/me/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC",
"type":"stdio"}
The problem of course is that we cannot directly use that Flatpak bin but need the extra spawn step in between. What we need is a way to manipulate the definition file such that we can switch in a different path. systemd to the rescue!
systemctl edit --user --full --force keepassxc-native-messaging-mangler.path
\# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>
\[Path\]
PathChanged=/home/me/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc\_browser.json
\[Install\]
WantedBy=default.target
and the associated service file…
systemctl edit --user --full --force keepassxc-native-messaging-mangler.service
\# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>
\[Unit\]
Description=keepassxc mangler
\[Service\]
ExecStart=/home/me/keepassxc-native-messaging-mangler
lastly, enable the path unit.
systemctl --user enable --now keepassxc-native-messaging-mangler.path
Alright, there’s some stuff to unpack here. KeePassXC on startup writes the aforementioned definition file into Firefox’ NMH path. What we do with the help of systemd is monitor the file for changes and whenever it changes we’ll trigger our service, the service runs a mangler to modify the file so we can run another command instead. It’s basically an inotify watch.
Here’s the mangler (~/keepassxc-native-messaging-mangler):
#!/usr/bin/env ruby
# frozen\_string\_literal: true
# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>
require 'json'
file = "#{Dir.home}/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/org.keepassxc.keepassxc\_browser.json"
blob = JSON.parse(File.read(file))
blob\['path'\] = "#{Dir.home}/Downloads/keepassxc"
File.write(file, JSON.generate(blob))
It simply replaces the path of the executable with a wrapper script. Here’s the wrapper script (~/Downloads/keepassxc):
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0-only OR GPL-3.0-only OR LicenseRef-KDE-Accepted-GPL
# SPDX-FileCopyrightText: 2023 Harald Sitter <sitter@kde.org>
exec /usr/bin/flatpak-spawn --host --watch-bus "$HOME/.local/share/flatpak/exports/bin/org.keepassxc.KeePassXC" "$@"
flatpak-spawn is a special command that allows us to spawn processes outside the sandbox. To gain access we’ll have to allow Firefox to talk with the org.freedesktop.Flatpak DBus session service.
flatpak override --user --talk-name=org.freedesktop.Flatpak org.mozilla.firefox
And that’s it!
➡️ KeePassXC writes its NMH definition to Flatpak specific path ➡️ systemd acts on changes and starts mangler ➡️ mangler changes the path inside the definition to our wrapper ➡️ Firefox reads the definition and calls our wrapper ➡️ wrapper flatpak-spawns KeePassXC flatpak ➡️ Firefox (flatpak) talks to KeePassXC (flatpak)