Sandboxing #154
Description
Cairo-Dock currently runs unsandboxed, meaning that bugs can potentially be turned into exploits. Specifically, it has full read / write access in $HOME, that it does not actually need. It would be good to limit permissions of Cairo-Dock to what is actually needed.
However, this is not easy, as Cairo-Dock needs to act as a launcher, which means that it needs to be able to start other processes, including potentially unsandboxed ones. Additional issues come from a wide range of DBus interfaces used by both the core and the plugins. E.g. the org.freedesktop.systemd1 interface that is currently used to launch apps would allow running arbitrary commands. Currently Cairo-Dock also uses system() to run arbitrary commands in some cases, while some plug-ins also rely on launching custom commands (via cairo_dock_launch_command* ()), but these could be worked around.
One possible way to improve this would be to separate Cairo-Dock into two separate binaries:
- The main Cairo-Dock process that contains most functionality, and runs in a bubblewrap sandbox that limits its access to parts of the filesystem absolutely necesary (config files + libraries needed, the X server / Wayland compositor). It is not allowed to run other processes. Access to D-Bus interfaces would also need to be filtered. Optionally access to opening files via xdg-desktop-portal or similar could be given (e.g. to open / save themes).
- A small proxy, written in a memory-safe language (e.g. Vala or Rust) that runs unsandboxed and is used to launch apps; it communicates with the main process by an IPC interface (e.g. a custom, peer-to-peer D-Bus) on which it can receive info about apps to launch. To actually provide a security benefit, instead of running arbitrary commands, this should be restricted to apps with a valid
.desktopfile installed on the system (so the main process would communicate only a .desktop file ID and optionally URIs to open).
The above two would be launched by an appropriate wrapper script; alternatively, the proxy could launch the main process, constructing an appropriate bubblewrap commandline.
Even with the above, it is unclear if we get a security benefit, as there could be many ways to circumvent it.