Sandboxing D-Bus-activated Applications #5529
glitsj16
started this conversation in
Show and tell
Replies: 1 comment 1 reply
-
firecfg.py supports this for over two years. And it supports autostart and experimental shell aliases for programs like ffmpeg or tar that frequently cause breakage of other programs like makepkg but can be firejailed when they are used directly by the user in a shell. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Quite some time ago I noticed this comment in the gjs.profile:
firejail/etc/profile-a-l/gjs.profile
Lines 8 to 10 in 65c92b4
At first I took it to suggest that sandboxing D-Bus activated applications is impossible to achieve with Firejail by design. That scratched an itch and I started to research this topic. Pretty soon it turned out there's actually nothing technical or code-wise in Firejail that keeps you from doing so.
With a bit of manual work you can in fact firejail those D-Bus activated applications. Most distributions use the
/usr/share/dbus-1/services
directory to store D-Bus units. Copy the unit file for the app you want to sandbox to eitherYou will need to edit this file, regardless where you placed it. Point the
Exec=foo
to a custom shell script and boom, firejail activated. Oh no, create yet another shell script? Well okay, let's do that.Here's an example for
dconf-editor
to get you going. The example uses system-wide files, but these can just as easily be per-user ones. Thelogic
stays the same.$ cat /usr/share/dbus-1/services/ca.desrt.dconf-editor.service
$ cat /etc/dbus-1/services/ca.desrt.dconf.service
$ cat /usr/bin/dconf-editor-fj
Now for the discussion. If there's an interest, I can add this to the wiki. All input is welcome and I'm very much open to clarify or answer any questions that might come up.
Beta Was this translation helpful? Give feedback.
All reactions