• X11Security

X Window System security

The biggest limitation of Plash for GUI programs is that the X Window System (X11) provides almost no security.

The X server allows an X client to:

• Snoop on the screen by reading its contents.
• Snoop on the keyboard.
• Take control of other X clients by sending them keyboard and mouse events.
• Impersonate other X clients by using their names in window title bars.
• Discover what other X clients are running.
• Steal the input focus.
• Deny service by grabbing the pointer or keyboard or the whole server.
• Deny service by consuming the X server's resources.

See:

• X11SecurityRequirements: list of requirements for securing X

• X11SecurityImplementation: discussion of implementation options

  • X11ProxySpike

• TrustedPathButtons

• AsynchronousWindowOpens

• X11Selections: notes on how X11's selection/clipboard mechanism operates

Existing security mechanisms

The X Security extension has been around for a long time but isn't much used because it is very limited. It divides clients into two protection domains, which it calls "trusted" and "untrusted". X clients within one protection domain can still interfere with each other. You really need a separate protection domain for each application.

SSH was changed to use XSecurity: The "-X" option now makes X clients connecting via ssh into "untrusted" clients. The "-Y" option makes them "trusted" clients. On Debian/Ubuntu systems, however, this feature is normally switched off, because it breaks many applications. See the ForwardX11Trusted setting in the ssh_config man page.

New security mechanisms: XACE

XACE (X Access Control Extension) is being added to the Xorg X server. It generalises the hooks that XSecurity added and makes them available to other extensions. See XACE.

XSELinux

One such extension is XSELinux, which uses SELinux to make security decisions according to SELinux's centralised policy. When a process connects to the X server, XSELinux finds out its identity (security context) using getpeercon(), a SELinux-specific system call. (Plash does not provide anything analgous to getpeercon() because it is not an identity-based security system.)

It is not clear how XSELinux will provide secure labelling of windows (eg. via title bars). This requires changes to window managers. It presumably requires a new X request for getting the "security context" of a window, analagous to getpeercon(). If this is added, will it be SELinux-specific?

References:

• Paper: Securing the X Window System with SELinux, Doug Kilpatrick, Wayne Salamon, Chris Vance (NAI Labs), 2003

• Paper: Application of the Flask Architecture to the X Window System Server, Eamon F. Walsh (NAI Labs), SELinux Symposium 2007

• http://people.freedesktop.org/~ewalsh/xace_proposal.html

Related work

• Design of the EROS Trusted Window System, Jonathan S. Shapiro, John Vanderburgh, Eric Northup and David Chizmadia, 2004.

Related problems on Windows

Windows has a similar problem to X11. On Windows, attacks involving sending keypress events to another application are known as "shatter attacks".

• Shatter-proofing Windows, Tyler Close, Alan H Karp and Marc Stiegler, 2005