Tray-icon researches

[rusty-snake]

There are many tray-icon standards:

• XEmbed.
  • is legacy
  • uses X
  • has no wayland support therefore
  • independent on DBus
• A Unity/Ubuntu special standard
  • not implemented in Xfce, KDE, ...
  • applications cann't relay on it
• StatusNotifierItem (freedesktop) (org.freedesktop.StatusNotifierWatcher)
  • actually there is no implementation by Apps or DE (has xfce one?)
  • was submitted by kde based on the one below
• KStatusNotifierItem (KDE) (org.kde.StatusNotifierWatcher)
  • is used by sway, GNOME via shell-extension, KDE, ...
  • KDE has maybe some additional additions
  • I tested under GNOME for now
  • this it the one I focus below
• ...

Which dbus rules are requiered for KStatusNotifierItem?

• dbus-user.talk org.kde.StatusNotifierWatcher
  • This is unsafe and allows sandbox escapes
  • This is always required
• dbus-user.own <APP-ID> (or dbus-user.own <Apps Indicator Service> but I never saw it)
  • This is required by apps using libayatana (e.g. transmission-gtk)
• dbus-user.own org.kde.StatusNotifierItem-<PID>-<ID>
  • This is required by apps strictly following the spec (e.g. Qt based)
  • YES YOU READ IT RIGHT, <PID>!! fuck yeah!
  • The pid is part of the name, meaning you need to add dbus-user.own org.kde.* (obviously unsafe)
  • The pid inside the sandbox is used, this means
    • These names are a bit stable if it is for example the second process in the sandbox which registers a tray-icon
    • Names can conflict and apps likely don't expect a other program with the same pid

[rusty-snake]

The pid is part of the name, meaning you need to add dbus-user.own org.kde.* (obviously unsafe)

The alternative is to add hundreds of dbus-user.own org.kde.StatusNotifierItem-<PID>-<ID> commands. However, this takes endless to start firejal.

with open("/proc/sys/kernel/pid_max", "r") as pid_max_fd:
    pid_max = int(pid_max_fd.read())

with open("snw.inc", "w") as snw_inc:
    snw_inc.write("dbus-user.call org.kde.StatusNotifierWatcher=org.freedesktop.DBus.Introspectable.*\n")
    snw_inc.write("dbus-user.call org.kde.StatusNotifierWatcher=org.freedesktop.DBus.Properties.*\n")
    snw_inc.write("dbus-user.call org.kde.StatusNotifierWatcher=org.kde.StatusNotifierWatcher.*@/StatusNotifierWatcher\n")
    for pid in range(pid_max):
        for i in range(9):
            snw_inc.write(f"dbus-user.own org.kde.StatusNotifierItem-{pid}-{i}\n")

[crocket]

Have you found a way to sandbox applications that use StatusNotifierItem?

[crocket]

Even if PID is the same, ID can be different. But, clashes can still happen.

StatusNotifierItem

Each application can register an arbitrary number of Status Notifier Items by registering on the session bus the service org.freedesktop.StatusNotifierItem-PID-ID, where PID is the process id of the application and ID is an arbitrary numeric unique identifier between different instances registered by the same application.

Perhaps, you should talk with freedesktop guys.

[rusty-snake]

actually there is no implementation by Apps or DE _{(see OP)}

[crocket]

The KDE version is similar, and it is easy to change specification when there is no implementation.

[rusty-snake]

IMHO there should be something like a org.freedesktop.portal.StatusNotifierItem.

[crocket]

I encourage you to talk about this with freedesktop guys. I don't know much about this.

[michelesr]

@rusty-snake can you provide detail on how dbus-user.talk org.kde.StatusNotifierWatcher allows sandbox escaping?

[rusty-snake]

The most implementations do not care about sandboxing and expose all objects/interfaces on all names. That means it effectively allows other names like org.gnome.Shell too.

Denied: dbus-send --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'"malicious payload"'
Allowed: dbus-send --print-reply --dest=org.kde.StatusNotifierWatcher /org/gnome/Shell org.gnome.Shell.Eval string:'"malicious payload"'

[michelesr]

is that true also for other things such as org.freedesktop.Notifications? doesn't that make the whole dbus filtering useless, making dbus disabling the only viable option?

[rusty-snake]

org.freedesktop.Notifications

https://github.com/netblue30/firejail/wiki/Restrict-DBus

doesn't that make the whole dbus filtering useless

• No, you can still use filter to allow IPC (e.g. dbus-user.own org.mozilla.firefox.*)
• There are safe names. Mostly DE provided names are affected.

making dbus disabling the only viable option?

(unlike flatpak,) firejail allows you to specify call and broadcast policies to filter the objects,interfaces,methods on a name that should be allowed. However they are long, complex, ugly and hard to maintain, that's why they are not used by upstream profiles ATM.

[opqriu]

os: debian 12 gnome 43

I started seeing the steam tray icon properly by doing the following.

-.

In the path "/var/lib/dpkg/info", look for a "list" file with the app name.

Found the file "steam-launcher.list"!

Open it with an editor and search for "png", and you'll find the suspect.

"/usr/share/pixmaps/steam_tray_mono.png"

Put the file "steam_tray_mono.png" in the path /home/firejail/Steam/.local/share/icons.

How I run steam :
~$ firejail --private=$HOME/firejail/Steam steam -forcedesktopscaling 2.0 -silent

-.

The tray icon shows the steam image normally. (Previously, when running with firejail --private, the tray icon image was not displayed correctly).

But... 🤔🤔🤔🤔🤔
Tray icon images are very visible even after deleting the /home/firejail/Steam/.local/share/icons folder.

I'm not sure how or why this worked for me. Anyway, that's good
It worked, but I don't know why it worked. Anyway, that's good