# X11 Security Architecture, Client Isolation Limitations & Dual-Boundary Model

Phase 5 Security Disclosure & Confinement Boundary Specification
Author: Snigdha OS Engineering Core
Applicability: Snigdha OS Decentralized (i3wm / X11 Edition)

# 1. Executive Disclosure

Snigdha OS Decentralized operates the i3wm tiling window manager over the Xorg (X11) display server. While i3wm delivers a deterministic, minimal-overhead, and predictable live desktop environment, the X11 protocol was architected under the legacy premise that all client connections to an X server are mutually trusted peers.

Filesystem sandboxing (bubblewrap), mandatory access control (AppArmor), and system call filtering (seccomp) cannot eliminate these shared-socket X11 protocol risks. Once a sandboxed application connects to the host X11 display socket, it communicates over the shared graphical bus.

# 2. The Dual-Boundary Security Architecture

To maintain rigorous engineering honesty and prevent false security assumptions, Snigdha OS explicitly separates its security architecture into two distinct trust boundaries:

+-----------------------------------------------------------------------------------+
|                           SNIGDHA OS CONFINEMENT MODEL                            |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ BOUNDARY 1: Operating System & Platform Resources ] (STRICTLY ISOLATED)         |
|  ----------------------------------------------------------------                 |
|  Enforced By: AppArmor + Bubblewrap + Seccomp + xdg-dbus-proxy                     |
|  Protects:                                                                        |
|    * Filesystem access (strictly read-only /usr, private volatile tmp)            |
|    * Process & IPC boundaries (unshared PID/IPC namespaces, peer PIDs hidden)     |
|    * Network enforcement (host-enforced Tor interception or offline loopback)     |
|    * Encrypted Persistent storage (masked with empty tmpfs when locked)          |
|    * Host credentials (/etc/shadow, GnuPG private keys, SSH keys denied)          |
|    * D-Bus IPC (proxy blocks privileged interfaces: NetGuard, Persistence, systemd)|
|    * System calls (kernel modules, ptrace, syslog, reboot blocked via seccomp)    |
|                                                                                   |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  [ BOUNDARY 2: Shared X11 Display Protocol ] (SHARED TRUST BOUNDARY)              |
|  ----------------------------------------------------------------                 |
|  Protocol: X11 Core Protocol over /tmp/.X11-unix/X0                                |
|  Inherent Limitations:                                                            |
|    * Display server cannot authenticate client event origins                      |
|    * Any connected client can observe pixel data from peer windows                |
|    * Global clipboard buffers are shared across all active GUI clients            |
|    * Window hierarchy enumeration and subwindow scraping remain possible          |
|                                                                                   |
+-----------------------------------------------------------------------------------+

# Boundary 1 Protection Scope

Boundary 1 protects system binaries, kernel interfaces, memory spaces, user credentials, network traffic, encrypted persistence, and session D-Bus interfaces. Even if an application is compromised by an in-memory exploit or malicious document, Boundary 1 prevents it from:

• Persisting across reboots (blocked by Amnesia volatile tmpfs).
• Accessing host documents or SSH/GPG credentials (blocked by namespace & AppArmor rules).
• Bypassing Tor network enforcement (blocked by NetGuard nftables rules).
• Accessing encrypted persistent volumes (blocked by storage masking).
• Tracing or injecting code into peer processes (blocked by PID namespace and seccomp ptrace denial).

# Boundary 2 Exposure Scope

Boundary 2 covers the shared graphical display session. A malicious graphical client sharing the host $DISPLAY could theoretically log keystrokes typed into another graphical client or scrape desktop pixels while both applications are running concurrently on the display.

# 3. Technical Anatomy of X11 Inherent Vulnerabilities

# 3.1 Keystroke Interception

Under standard X11, any client can request event notifications for global key events using functions like XSelectInput on the root window or XGrabKeyboard. Malicious software running on the host display can monitor keystrokes, password entries, and encryption keys entered into other GUI applications.

# 3.2 Screen Observation & Window Scraping

X11 does not compartmentalize window buffers from peer processes. Any client can issue an XGetImage or XShmGetImage call targeting the root window or peer subwindows. Consequently, an untrusted binary can snapshot or record the entire desktop without administrative elevation.

# 3.3 Synthetic Input Injection

X11 extensions such as XTest and protocol messages (XSendEvent) allow clients to inject simulated keyboard presses and mouse clicks directly into other windows. A malicious process could, for example, wait until a terminal window gains focus and inject commands.

# 3.4 Clipboard Snooping and Hijacking

The X11 selection architecture (CLIPBOARD, PRIMARY) is a shared global mechanism. Any client can inspect pasted data, steal passwords or crypto addresses from the clipboard, or replace copied text with adversarial payload strings.

# 4. Evaluation of Nested X Servers (Xephyr) and Mitigations

As part of Phase 5 research, Snigdha OS investigated Xephyr (nested X server) containment for untrusted applications:

# 4.1 How Xephyr Operates

Xephyr is an X server that runs as an ordinary client window within the parent X11 display. A child application is launched with DISPLAY=:1 pointing exclusively to the Xephyr nested server, while the host display remains on DISPLAY=:0.

# 4.2 Security Benefits Observed

1. Keystrokes inside Xephyr cannot be read by clients on the host :0 display via root window queries.
2. Keystrokes on the host :0 display cannot be observed by applications trapped inside the Xephyr :1 server.
3. The child application has access only to the Xephyr display hierarchy; it cannot call XGetImage on parent desktop windows.

# 4.3 Technical Trade-offs & Limitations

1. Host-to-Guest Observation: The parent host X server can still capture the pixel contents of the Xephyr window itself. Xephyr protects the host from the guest, but does not protect the guest from compromised host clients.
2. Clipboard & Portal Friction: Sharing clipboard data or opening file choosers between nested displays requires custom clipboard forwarders and portal proxies, introducing desktop usability latency.
3. Resource Overhead: Each nested X server requires dedicated memory buffers, rendering loops, and IPC pipes, which degrades performance on resource-constrained hardware (4 GB RAM live sessions).
4. Window Management Conflicts: i3wm tiles the entire Xephyr window as a monolithic rectangle, preventing native window tiling, workspace switching, and keybinding management for sub-windows inside the guest.

# 4.4 Phase 5 Engineering Conclusion

Xephyr is maintained as an experimental mitigation tool for untrusted graphical utilities. However, it is not enabled as a mandatory default for standard desktop utilities because it impairs i3wm's native tiling workflow without providing the complete memory and hardware security guarantees of a genuine Wayland architecture.

# 5. Strategic Path to Wayland

True, protocol-level mutual GUI client isolation can only be achieved through Wayland compositors (such as wlroots or sway):

• Client window buffers are strictly private and unreadable by peer applications.
• Keystrokes are delivered exclusively to the focused window surface.
• Synthetic input injection between clients is forbidden by protocol specification.
• Screen recording and clipboard sharing require explicit user authorization via desktop portals (xdg-desktop-portal).

Snigdha OS maintains i3wm on Xorg for Phase 5 to deliver rock-solid stability and deterministic memory cleanup. The Wayland migration remains planned for subsequent major distribution milestones.