implement xdg-dbus-proxy --log / log denied D-Bus access tries

[rusty-snake]

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 #3265 (comment)

cc @kris7t

[kris7t]

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).

[rusty-snake]

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).