X11 Clipboard Security: Sandbox Linux Zoom With Flatpak

You copy an API key, an SSH password, or a sensitive configuration snippet on your workstation. You join a daily standup. Before you even hit Ctrl+V, the proprietary meeting software has already requested and read your clipboard contents.

This is the reality of running the Linux Zoom client on a traditional X11 desktop environment. Simon Tatham, the developer of PuTTY, documented that Zoom 7.1.5 on X11 reads the clipboard proactively: whenever another application takes ownership of the CLIPBOARD selection, Zoom is notified and immediately requests its contents, without any paste and without needing focus. That includes passwords copied from a password manager. Reports say it leaves the PRIMARY (middle-click) selection alone. (Hacker News discussion, Neowin)

This behavior highlights a severe architectural flaw in X11 clipboard security. X11 lacks an isolation model. Any connected graphical client can query the global clipboard state at any time. When you combine decades-old graphical protocols with closed-source, telemetry-heavy communication tools, your workstation becomes a massive data leak liability.

Fixing this requires isolating the application. You must abandon X11, force the application into a native Wayland context, and use Flatpak sandbox Zoom configurations backed by Bubblewrap to explicitly deny unauthorized access to host resources.

The X11 Architecture Flaw

The X Window System dates back to the 1980s. The protocol assumes all graphical clients running on the same display server trust each other. There is no permission model, no manifest file, and no user prompt for resource access.

X11 manages copied data using a system of “selections.” When you highlight text, the client holding that text claims ownership of the PRIMARY selection. When you explicitly copy text (Ctrl+C), a client claims the CLIPBOARD selection. The X server does not store the copied data centrally. Instead, it tracks which client window currently owns the selection.

When a different application requires the copied data, it sends a SelectionRequest event to the X server. The X server forwards this request to the owning window. The owning window replies with the data, and the requesting window receives it.

Under X11, any client can request a selection at any time, and the XFIXES extension lets a client be notified whenever selection ownership changes. That is the mechanism the reports describe: Zoom watches for a new CLIPBOARD owner and requests the data at once.

If you are performing linux security hardening on your workstation or homelab management machine, running untrusted binaries directly on an X11 server negates your other security policies.

Verifying the Snooping Behavior

You can observe this data exfiltration mechanically. X11 provides tools to monitor protocol events in real time.

Tatham found it by tracing the X protocol traffic between Zoom and the X server: each time something new is copied, a conversion request for CLIPBOARD from Zoom follows immediately. Any X protocol tracer that sits between a client and the X server will show the same pattern.

The Wayland and Bubblewrap Solution

Wayland compositors handle clipboard interactions differently. The compositor mediates all data transfers between windows. Background applications cannot request the clipboard contents. The compositor only grants access to the window that currently holds explicit user focus, and modern compositors further restrict programmatic reads unless initiated by a user input event (like a keystroke).

However, switching to Wayland is only half the fix.

Proprietary applications often ship with legacy X11 dependencies and default to running via XWayland (a compatibility layer). Applications running within the same XWayland instance still share a unified X11 protocol environment, meaning they can still intercept each other’s clipboards. Furthermore, executing the binary directly on your host file system grants the application read access to your ~/.ssh directories, configuration files, and bash history.

To enforce strict boundaries, you must use Flatpak. Flatpak utilizes Bubblewrap to create unprivileged Linux containers. Bubblewrap processes the application in isolated mount, network, and IPC namespaces. By utilizing Flatpak permission overrides, you can explicitly strip X11 socket access, force native Wayland, and sever host filesystem access.

Sandboxing Zoom: Step-by-Step

First, install the Zoom application via Flathub. Flathub provides a packaged version of the official binary, wrapping it in the necessary runtime dependencies.

flatpak install flathub us.zoom.Zoom

The Flathub package grants both the x11 and wayland sockets, so it works on X11 desktops too. It does not get your home directory: only ~/Documents/Zoom and its own ~/.zoom data. The X11 socket is the part to remove. This only works in a Wayland session: on an X11 desktop, an app without the X11 socket has no display to open. If you’re on X11, switching the session to Wayland is the real fix.

Use the flatpak override command to modify the Bubblewrap namespace parameters for this specific application.

# 1. Reset any existing user overrides
flatpak override --user --reset us.zoom.Zoom

# 2. Apply strict isolation rules
flatpak override --user \
  --nosocket=x11 \
  --nosocket=fallback-x11 \
  --socket=wayland \
  --socket=pulseaudio \
  --share=network \
  --device=all \
  --nofilesystem=host \
  --nofilesystem=home \
  --persist=.zoom \
  --talk-name=org.freedesktop.ScreenSaver \
  us.zoom.Zoom

Breaking Down the Overrides

The overrides command dictates the exact flags passed to Bubblewrap at execution time.

• --nosocket=x11 and --nosocket=fallback-x11: Zoom can no longer connect to an X server or XWayland, so the X11 clipboard is out of reach. The package leaves Qt’s platform choice open, so in a Wayland session Zoom can use Wayland natively. If it doesn’t start after this change, it needed X11 on your setup: remove the override and keep it off X11 some other way.
• --socket=wayland: This grants access strictly to the native Wayland compositor socket.
• --nofilesystem=host and --nofilesystem=home: These parameters block the application from reading your host root and home directories.
• --persist=.zoom: keeps Zoom’s settings in ~/.var/app/us.zoom.Zoom/.zoom (the package already does this; repeating it is harmless).

Resolving Screensharing Requirements

Enforcing this strict isolation introduces a practical limitation. Legacy screensharing on Linux relies on the X11 shared memory extension (XShm) or direct X11 root window capture. By blocking X11 sockets, traditional screensharing mechanisms fail completely.

To share your screen in the sandboxed Wayland environment, the system must utilize the XDG Desktop Portal and PipeWire.

The XDG Desktop Portal acts as a secure D-Bus interface. When the Zoom application needs to capture the screen, it cannot read the frame buffer directly. Instead, it sends a request to the portal. The portal triggers your Wayland compositor to display a native, system-level prompt asking you to select a specific screen or window. Once authorized, PipeWire streams the video frames directly to the application namespace.

Ensure you have the required packages installed on your host system:

# On Debian/Ubuntu variants
sudo apt install xdg-desktop-portal xdg-desktop-portal-gnome pipewire wireplumber

# On Fedora/RHEL variants
sudo dnf install xdg-desktop-portal xdg-desktop-portal-gtk pipewire wireplumber

Then test screen sharing in a meeting: on Wayland, the portal should show your desktop’s own picker for choosing a screen or window. If the client fails to detect the portal, check systemctl --user status xdg-desktop-portal.service to confirm the portal daemon is active.

By stripping X11 access and wrapping the binary in a tightly constrained Bubblewrap namespace, the application can no longer poll your clipboard or index your filesystem. The operating system forces the binary to request resources through mediated, user-approved channels, restoring control over your local data.

What’s Next

• Linux Homelab Security Hardening: Complete Checklist (2026)
• Your Container Is Not a Sandbox: Use MicroVMs Instead
• Trusting Trust Attacks: Secure Your Linux Homelab