github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #3402] implement xdg-dbus-proxy --log / log denied D-Bus access tries #2138

New issue

Closed

opened 2026-05-05 08:49:00 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 08:49:00 -06:00

Owner

Originally created by @rusty-snake on GitHub (May 4, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3402

Originally assigned to: @kris7t on GitHub.

Implement xdg-dbus-proxy --log to log blocked D-Bus calls. Without this it is difficult debug things like #3400 or #3399.

Alternative we could log all calls for writing for writing profiles or simply forward the --log output (stdout of xdg-dbus-proxy) to a file (e.g. /tmp/pid_of_sandbox-dbus) and parse it with a python/bash/... program in contrib.

cc @kris7t

Originally created by @rusty-snake on GitHub (May 4, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3402 Originally assigned to: @kris7t on GitHub. Implement xdg-dbus-proxy --log to log blocked D-Bus calls. Without this it is difficult debug things like #3400 or #3399. _Alternative we could log all calls for writing for writing profiles or simply forward the --log output (stdout of xdg-dbus-proxy) to a file (e.g. /tmp/pid_of_sandbox-dbus) and parse it with a python/bash/... program in contrib._ see also https://github.com/netblue30/firejail/pull/3265#issuecomment-609477194 cc @kris7t

gitea-mirror

2026-05-05 08:49:00 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:49:03 -06:00

Author

Owner

@kris7t commented on GitHub (May 4, 2020):

Sorry for not getting back to this earlier. I think capturing xdg-dbus-proxy output is the way forward, then post-processing it with a script (either to create a more human-readable log, or to generate profile line directly). The format of the logs looks way too annoying to process in a C program.

A complication is that xdg-dbus-proxy doesn't log separately for the session and system buses. Sometimes, interactive with the session and system buses is easily to filter out, but some names may be present on both buses. So to avoid confusion, I am now experimenting with single --dbus-user.log and --dbus-session.log options, as well as a dbus-log= option to direct output to a log file. A post-processing Python script may attempt to ingest a single log, connecting to the session and system buses to discern where each names belong (this can be somewhat of an approximation, if some names have disappeared since generating the log file), or take two logs (but then we have to run the application with logging two separate times).

Another annoyance is that while filter rules are bound to well-known names, but communication on the bus might use unique names. See e.g.,

C1: -> org.freedesktop.DBus call org.freedesktop.DBus.Hello at /org/freedesktop/DBus
C2: -> org.freedesktop.DBus fake AddMatch for org.freedesktop.Notifications
C3: -> org.freedesktop.DBus fake GetNameOwner for org.freedesktop.Notifications
B1: <- org.freedesktop.DBus return from C1
B2: <- org.freedesktop.DBus signal org.freedesktop.DBus.NameAcquired at /org/freedesktop/DBus
B3: <- org.freedesktop.DBus return from C2
*SKIPPED*
B4: <- org.freedesktop.DBus return from C3
*SKIPPED*
C4: -> org.freedesktop.DBus call org.freedesktop.DBus.AddMatch at /org/freedesktop/DBus
C5: -> org.freedesktop.DBus call org.freedesktop.DBus.AddMatch at /org/freedesktop/DBus
C6: -> org.freedesktop.DBus call org.freedesktop.DBus.StartServiceByName at /org/freedesktop/DBus
B5: <- org.freedesktop.DBus return from C4
B6: <- org.freedesktop.DBus return from C5
B7: <- org.freedesktop.DBus return from C6
C7: -> org.freedesktop.DBus call org.freedesktop.DBus.GetNameOwner at /org/freedesktop/DBus
B8: <- org.freedesktop.DBus return from C7
C8: -> :1.4 call org.freedesktop.Notifications.GetServerInformation at /org/freedesktop/Notifications
B189: <- :1.4 return from C8
C9: -> :1.4 call org.freedesktop.Notifications.Notify at /org/freedesktop/Notifications
B190: <- :1.4 return from C9

which is a log from notify-send "foo". There is no mention of org.freedesktop.Notifications as bus name anywhere, we instead get :1.4. Filter rules are "sticky" to bus names, so even though I had --dbus-user.call=org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications, the call went through: :1.4 also holds the bus name org.freedesktop.Notifications. So we probably need the helper script to connect to the bus, and try to resolve unique names into well-known names. Now, a program might hold multiple well-know names, but only one will make sense for a filter rule (org.freedesktop.Notifications instead of org.gnome.Shell, for example), so we might also need some heuristics (e.g., pick the well-known name most similar to the object path or interface name). But relations between these names are loose enough in practice that some manual intervention may be needed nevertheless.

In principle, we could even generate very fine-grained policies with --call and --broadcast filters that take bus name, interface member, object path triples. I added --dbus-{user,system}.{call,broadcast}= options to firejail to this end. However, these profiles can be unwieldy to write (hence the need for automatic generation from logs).

@kris7t commented on GitHub (May 4, 2020): Sorry for not getting back to this earlier. I think capturing `xdg-dbus-proxy` output is the way forward, then post-processing it with a script (either to create a more human-readable log, or to generate profile line directly). The format of the logs looks way too annoying to process in a C program. A complication is that `xdg-dbus-proxy` doesn't log separately for the session and system buses. Sometimes, interactive with the session and system buses is easily to filter out, but some names may be present on both buses. So to avoid confusion, I am now experimenting with single `--dbus-user.log` and `--dbus-session.log` options, as well as a `dbus-log=` option to direct output to a log file. A post-processing Python script may attempt to ingest a single log, connecting to the session and system buses to discern where each names belong (this can be somewhat of an approximation, if some names have disappeared since generating the log file), or take two logs (but then we have to run the application with logging two separate times). Another annoyance is that while filter rules are bound to well-known names, but communication on the bus might use unique names. See e.g., ``` C1: -> org.freedesktop.DBus call org.freedesktop.DBus.Hello at /org/freedesktop/DBus C2: -> org.freedesktop.DBus fake AddMatch for org.freedesktop.Notifications C3: -> org.freedesktop.DBus fake GetNameOwner for org.freedesktop.Notifications B1: <- org.freedesktop.DBus return from C1 B2: <- org.freedesktop.DBus signal org.freedesktop.DBus.NameAcquired at /org/freedesktop/DBus B3: <- org.freedesktop.DBus return from C2 *SKIPPED* B4: <- org.freedesktop.DBus return from C3 *SKIPPED* C4: -> org.freedesktop.DBus call org.freedesktop.DBus.AddMatch at /org/freedesktop/DBus C5: -> org.freedesktop.DBus call org.freedesktop.DBus.AddMatch at /org/freedesktop/DBus C6: -> org.freedesktop.DBus call org.freedesktop.DBus.StartServiceByName at /org/freedesktop/DBus B5: <- org.freedesktop.DBus return from C4 B6: <- org.freedesktop.DBus return from C5 B7: <- org.freedesktop.DBus return from C6 C7: -> org.freedesktop.DBus call org.freedesktop.DBus.GetNameOwner at /org/freedesktop/DBus B8: <- org.freedesktop.DBus return from C7 C8: -> :1.4 call org.freedesktop.Notifications.GetServerInformation at /org/freedesktop/Notifications B189: <- :1.4 return from C8 C9: -> :1.4 call org.freedesktop.Notifications.Notify at /org/freedesktop/Notifications B190: <- :1.4 return from C9 ``` which is a log from `notify-send "foo"`. There is no mention of `org.freedesktop.Notifications` as bus name anywhere, we instead get `:1.4`. Filter rules are "sticky" to bus names, so even though I had `--dbus-user.call=org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications`, the call went through: `:1.4` also holds the bus name `org.freedesktop.Notifications`. So we probably need the helper script to connect to the bus, and try to resolve unique names into well-known names. Now, a program might hold multiple well-know names, but only one will make sense for a filter rule (`org.freedesktop.Notifications` instead of `org.gnome.Shell`, for example), so we might also need some heuristics (e.g., pick the well-known name most similar to the object path or interface name). But relations between these names are loose enough in practice that some manual intervention may be needed nevertheless. In principle, we could even generate very fine-grained policies with `--call` and `--broadcast` filters that take bus name, interface member, object path triples. I added `--dbus-{user,system}.{call,broadcast}=` options to firejail to this end. However, these profiles can be unwieldy to write (hence the need for automatic generation from logs).

gitea-mirror commented

2026-05-05 08:49:04 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 4, 2020):

Thanks for the explanations.

I think capturing xdg-dbus-proxy output is the way forward, then post-processing it with a script (either to create a more human-readable log, or to generate profile line directly).

Going this way, would allow different scripts for different things (generate profile, warn on violation, ...)

Another annoyance is that while filter rules are bound to well-known names, but communication on the bus might use unique names. See e.g.,

From that what I saw (with --log and dbus-monitor) the output still contains the addresses (at least one time).

@rusty-snake commented on GitHub (May 4, 2020): Thanks for the explanations. > I think capturing xdg-dbus-proxy output is the way forward, then post-processing it with a script (either to create a more human-readable log, or to generate profile line directly). Going this way, would allow different scripts for different things (generate profile, warn on violation, ...) > Another annoyance is that while filter rules are bound to well-known names, but communication on the bus might use unique names. See e.g., From that what I saw (with --log and `dbus-monitor`) the output still contains the addresses (at least one time).

gitea-mirror referenced this issue

2026-05-05 10:15:17 -06:00

[PR #2138] [MERGED] Fix incorrect --list and --tree output under certain circumstances #4184

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2138

No description provided.

Rows
Columns