DBus filtering enhancements

[kris7t]

This PR exposes additional functionalities from xdg-dbus-proxy:

• --dbus-user.see and --dbus-system.see allow setting the SEE policy for DBus names.

• --dbus-{user,system}.{call,broadcast} allows setting per interface and per object path policies. For example, we can set

  dbus-user.call org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications
  dbus-user.broadcast org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications
  

  to safely allow notifications without exposing additional objects (e.g. /org/gnome/Shell).

• --dbus-{user,system}.log to turn on DBus proxy logging (implement xdg-dbus-proxy --log / log denied D-Bus access tries #3402). Unfortunately, this is not as useful as it may seem, because without --filer, xdg-dbus-proxy --log will not actually log anything. So we can use the options for debugging applications that fail due to DBus filters, but not for building DBus profiles from scratch.

In addition, this PR updates faudit so it won't report MAYBE when DBus filters are in effect (#3326 (comment)).

A next step would be to either find a better DBus logging option (maybe with dbus-monitor), or stay with this one, and create some contrib scripts to generate filter rules from (rejected) DBus communications.

[rusty-snake]

Becoming complex 🤯.

1. dbus-{user,system}.see will be mostly to unbreak apps while still restricting those addresses. Right?
2. dbus-{user,system}-log 🥇
3. dbus-{user,system}.{call,broadcast} does dbus-user.call org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications imply dbus-user.talk org.freedesktop.Notifications (with restirction)? If so, we could provide a include dbus.inc(with a better name) that is included and restricts common addresses. Like

include dbus.inc
dbus-user filter
dbus-user.talk org.freedesktop.Notifications

which would allow o.f.N, but only as o.f.N.

[kris7t]

1. Well, it means the app can find out that the bus name is being held by someone, and retrieve the objects from that bus name by introspection. So the app will know that it shouldn't take ownership of the name. However, if it tries to talk to objects exposed by the bus name, it will still fail, and may crash the application if it is not prepared for D-Bus errors.
2. Yeah, it works to some extends, but not as useful as I'd hoped (no logging unless filtering is active).
3. call and broadcast imply see (and potentially relax it). So if you have dbus-user.call org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notifications, that means the application can see the org.freedesktop.Notifications name, but only method calls of the interface org.freedesktop.Notifications to the object /org/freedesktop/Notifications will be successful. So it is pointless to combine this with talk, which would relax the policy even further (any method call succeeds and any signal can be received). call/broadcast should mostly be used in pairs, e.g., if you have call on org.freedesktop.Notifications, but not broadcast, you won't be called back if the user click the notification. So we could have something like dbus-notifications.inc with:

dbus-user.call org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notification
dbus-user.broadcast org.freedesktop.Notifications=org.freedesktop.Notifications.*@/org/freedesktop/Notification

and then

include dbus-notifications.inc

in any profile that needs access to the notification daemon.

[kris7t]

Sorry for not checking back earlier, I was unfortunately very busy with projects at uni.

Does this look good to merge?

[rusty-snake]

From the (low-level) profile interface standpoint, yes.

[rusty-snake]

@kris7t xdg-dbus-proxy is started with arg0=3 which looks really strength in system-monitoing tools.

[glitsj16]

Confirming @rusty-snake's observation. E.g. when running dconf-editor the xdg-dbus-proxy process shows up with process names 0 in gnome-system-monitor. Not sure if there is anything that can be done about it, but if that's the case we can add it to the wiki page to avoid confused users filing issues on it.

[kris7t]

@rusty-snake @glitsj16 That might be a side effect of using fexecve to start /usr/bin/xdg-dbus-proxy and gnome-system-monitor getting a bit confused. argv[0] should certainly be "/usr/bin/xdg-dbus-proxy", but this is a bit weird, because we are starting it from and fd and not a path (#3241). This is done so that there is TOCTOU bug when we refuse to execute binaries that are world-writable or not owned by root during sandbox setup (the sandboxed binary itself can have any permissions, but we try to be a bit more stringent during sandbox setup, when SECCOMP filters and AppArmor are not in full effect).

At least for me, the correct /usr/bin/xdg-dbus-proxy name shows up when I view the process tree in htop. So this behavior might be a bug in xdg-system-monitor.

[glitsj16]

@kris7t Thanks for explaining, very informative. Using htop does indeed show the correct name. Personally I don't think it's a high-priority issue, but I'll try to file a bug report somewhere nonetheless. Take care!

[rusty-snake]

@kris7t 👍 Just a question for my understanding, why we can not simply execute fexecve(3, ["xdg-dbus-proxy", "--filter", ...], ...)?

[kris7t]

@rusty-snake That's exactly what we are doing:

firejail/src/firejail/sbox.c

Line 233 in d1dd363

fexecve(fd, arg, new_environment);

Here arg is the argv passed to the binary we want to exec. First we fopen arg[0], fstat it to check permissions, and if there is no tampering, we fexecve the opened fd, and pass the full arg (including arg[0], which should be "/usr/bin/xdg-dbus-proxy" in our case now), as well as the sanitized environment.

[rusty-snake]

At least for me, the correct /usr/bin/xdg-dbus-proxy name shows up when I view the process tree in htop. So this behavior might be a bug in xdg-system-monitor.

Hmm, ps -eH shows me 3, ps -eFH /usr/bin/xdg-dbus-proxy --fd=9 --args=10.