locally-written launch script unexpectedly allows sandboxed app to overwrite its own .desktop file

[axet]

I'm running Telegram binary software under bwrap with limited access to file system. But one in a while I see telegram some how replace my starter desktop file with it's own script which causing next start of telegram become unprotected by bwrap.

Here is full bwrap command:

axet     3531936  0.0  0.0   3576  2092 ?        S    16:42   0:00 bwrap --dev-bind / / --tmpfs /home/axet --ro-bind /home/axet/bin /home/axet/bin --ro-bind /home/axet/.config /home/axet/.config --ro-bind /home/axet/.local/share/wineprefixes /home/axet/.local/share/wineprefixes --bind /home/axet/.cache/telegram-desktop /home/axet/.cache/telegram-desktop --bind /home/axet/.local/share/TelegramDesktop /home/axet/.local/share/TelegramDesktop --bind /home/axet/Downloads /home/axet/Downloads --bind /home/axet/Soft/telegram /home/axet/Soft/telegram --bind /tmp /tmp --bind /home/axet/Soft/telegram /home/axet/Soft/telegram /home/axet/Soft/telegram//Telegram

As you can see I only granted access only to some folders but somehow telegram changes ~/.local/share/applications and remove my telegram.desktop script adds its own script:

# ll .local/share/applications/ | grep teleg
-rwxrwxr-x+ 1 axet axet    612 авг  3 20:10 org.telegram.desktop._65f73dc27c0fb30cb1424daa92f46251.desktop

I have no idea how this happens. Maybe because simple mistake in launch scripts. Maybe dbus allow to create/replace old desktop files.

My startup scripts based on homebin shell script and dependent telegram sh script:

• https://gitlab.com/axet/homebin/-/blob/debian/homebin
• https://gitlab.com/axet/homebin/-/blob/debian/homebin.d/web/telegram

[smcv]

possible security issue

If you believe you have found a security vulnerability, please do not report it in public where anyone with malicious intent would be able to see it and benefit from it!

[smcv]

Maybe dbus allow to create/replace old desktop files

D-Bus itself does not, but services on the D-Bus session bus do.

If you give an application like Telegram unrestricted access to the D-Bus session bus, that is nearly always a sandbox escape (arbitrary code execution outside the sandbox): it can make something like systemd --user or flatpak-session-helper or gnome-session execute arbitrary code on its behalf by just asking nicely.

Similarly, access to various other sockets in $XDG_RUNTIME_DIR, like $XDG_RUNTIME_DIR/systemd/private, is enough for arbitrary code execution.

Making a meaningful security boundary requires a deny-by-default approach, so granting access to only limited things. --dev-bind / / is a huge red flag from that point of view. Please take a look at the bubblewrap invocation in something like Flatpak and you'll see how complicated it is to have a container where "desktop things" can still work - but all of that complexity is necessary, and Flatpak wouldn't have it if it wasn't needed. (In particular, Flatpak uses https://github.com/flatpak/xdg-dbus-proxy to filter access to the D-Bus session bus.)

[smcv]

As you can see I only granted access only to some folders

Yes, and in particular they do not include ~/.local/share/applications. I agree that with this command-line, it shouldn't be possible for Telegram to overwrite files in ~/.local/share/applications directly.

However, it can certainly overwrite files in that directory indirectly, by asking a component outside the sandbox to do the overwriting on its behalf. Sending requests on the D-Bus session bus is one possible way; there could be others. I don't know which indirect mechanism Telegram used. dbus-monitor --session, gdbus monitor --session or busctl monitor --user could tell you whether it is sending requests on the D-Bus session bus, but the session bus is unlikely to be the only privileged side-channel you have left open.

If you want a meaningful security boundary, then unrestricted access to the D-Bus session bus, /tmp and $XDG_RUNTIME_DIR is not possible: you will have to prevent or filter these accesses (and perhaps others). bubblewrap provides a toolkit for sandboxing apps, but it is not, itself, a ready-to-use sandbox. Higher-level components like Flatpak are closer to providing a ready-to-use sandbox based on bubblewrap.

My startup scripts based on homebin shell script and dependent telegram sh script

Sorry, we do not have the resources to provide detailed technical support for your own locally-written scripts. It's up to you to design a security policy, and then construct a bubblewrap command-line that implements your security policy.

If you can construct a test-case where bubblewrap allows something that you believe should have been denied by the command-line arguments that you gave it, please report that privately to security@lists.podman.io, flatpak-security at lists.freedesktop.org or https://github.com/containers/bubblewrap/security/advisories/new.

[axet]

First looks found correlations to D-Bus service:

org.freedesktop.DBus Interface -> ListNames()

Returns one name with:

org.telegram.desktop._65f73dc27c0fb30cb1424daa92f46251

which is exactly the same name of desktop file created in application folder:

org.telegram.desktop._65f73dc27c0fb30cb1424daa92f46251.desktop

I'll keep investigating.

[axet]

I have new bwrap script without --dev-bind and with dbus disabled (no /run/user/1000/bus access), but telegram still somehow managed to escape bwrap to replace my desktop launcher script with its own with no bwrap call.

bwrap --ro-bind / / --tmpfs /home --tmpfs /home/axet --tmpfs /tmp --tmpfs /var/tmp --tmpfs /run/user/1000 --unshare-pid --unshare-uts --unshare-cgroup-try --ro-bind /tmp/.X11-unix /tmp/.X11-unix --ro-bind /run/user/1000/pipewire-0 /run/user/1000/pipewire-0 --ro-bind /run/user/1000/pipewire-0.lock /run/user/1000/pipewire-0.lock --ro-bind /run/user/1000/pipewire-0-manager /run/user/1000/pipewire-0-manager --ro-bind /run/user/1000/pipewire-0-manager.lock /run/user/1000/pipewire-0-manager.lock --dev /dev --dev-bind /dev/dri /dev/dri --dev-bind /dev/snd /dev/snd --ro-bind /home/axet/bin /home/axet/bin --ro-bind /home/axet/.config /home/axet/.config --ro-bind /home/axet/.local/share/wineprefixes /home/axet/.local/share/wineprefixes --bind /home/axet/.cache/telegram-desktop /home/axet/.cache/telegram-desktop --bind /home/axet/.local/share/TelegramDesktop /home/axet/.local/share/TelegramDesktop --bind /home/axet/Downloads /home/axet/Downloads --bind /home/axet/Soft/telegram /home/axet/Soft/telegram --bind /home/axet/encfs/cfg.d/gamehere /home/axet/encfs/cfg.d/gamehere /home/axet/Soft/telegram/Telegram

ll ~/.local/share/applications/ | grep tele
-rwxrwxr-x 1 axet axet    612 сен 21 12:35 org.telegram.desktop._65f73dc27c0fb30cb1424daa92f46251.desktop