• X11SecurityRequirements

Requirements for securing the X Window System

Test suite

There are the beginnings of a test suite in the SVN repository at x11-security-tests.

Summary table

Access to X objects

Most of the security checks that the XSecurity extension added are concerned with accessing X objects -- windows, pixmaps, graphics contexts, etc. (Note that these are usually referred to as "resources" in X terminology. I think using the term "object" in this section makes it clearer that we are not talking about accounting for resource consumption.)

Most of the time, an X client should only be able to access objects it created itself. There are some exceptions for global objects.

Root window

• Clients need to be able to open windows as children of the root window. (This gets handled by the window manager via the SubstructureRedirect mechanism.) Affects CreateWindow and (less usually) ReparentWindow.

• Clients need to be able to read various properties on the root window.

XSEC_GRAB_SERVER: Server grabs

GrabServer should be disabled (either by returning an error or by ignoring it), unless the client has a special permission. It allows denial of service of the whole X server. The only way to release the grab without the client's co-operation is to switch to another virtual terminal to kill the grabbing X client.

GrabServer may be used as a synchronisation mechanism to ensure that no other clients' X requests are processed within a critical section. However, if an X client is limited to using only resources it created itself, there is no need for synchronisation with other X clients.

Keyboard/pointer grabs

• XSEC_GRAB_KBD: Keyboard grabs: disable?
• XSEC_GRAB_PTR: Pointer grabs: disable?

We can classify keyboard/pointer grabs into three kinds:

• Active grabs, which are initiated by the client using GrabKeyboard or GrabPointer.

• Passive grabs that are registered in advance by the client using GrabKey or GrabButton, and activated when the user presses a key or clicks a mouse button on a window.

• Implicit passive grabs: The X server establishes a grab automatically any time the user presses a mouse button, and releases the grab when the button is released. These grabs are not registered in advance. They do not apply to key presses.

XSecurity stops Gtk's pop-up (right-click) menus from working, including menus that pop up from buttons. (However, pull-down menus still work.) This happens because GrabPointer is returning NotViewable, which causes Gtk to abort the process of opening the menu. GrabPointer returns NotViewable because the grab window's "realized" flag is not set, which is because Gtk created it as an InputOnly window as a child of the root window and XSecurity prevents these from being mapped. The spec says: "If an InputOnly window owned by an untrusted client has a parent owned by a trusted client, all attempts to map the window will be ignored."

When pointer grabs are disabled, XEmacs menus partly work: Dragging to select a menu item works, but clicking twice does not work.

Some clients appear to use pointer grabs when opening menus (XEmacs, Gtk), others do not (Qt, e.g. Konqueror). Do they use passive or active grabs?

Top-level windows

Types of top-level window:

• Regular windows with borders
• Pop-up menus
• Tool tips
• XSEC_FULLSCREEN: Full screen windows: This should be implemented by the window manager rather than by the untrusted X client. The WM can provide a trusted-path menu option for full-screening a window.

Issues:

• Top-level windows without borders: should require a special permission. eg. Beep media player's main window does not have a border provided by the window manager.
• XSEC_TOP_IRREGULAR: Irregularly-shaped windows: should require a special permission. This is a window manager issue: the WM can easily reparent an irregular window to make it rectangular.

XSEC_TOP_LABEL: Window title bars: secure labels

There should be a mapping from X clients to their pet names, so that the window manager can display a client's pet name in its windows' title bars, providing unforgeable secure labels and preventing window spoofing.

Note that most clients already put their name into the WM_NAME property that window managers display in the title bar. There would be duplication if the WM displayed the client's pet name as well. If the pet name appears at the start or end of WM_NAME, maybe the window manager should strip it out first.

XSEC_TOP_MENU: OverrideRedirect windows

A number of top-level windows get opened with the OverrideRedirect bit set, which means that the window manager does not handle the window. The WM does not provide a window frame and does not get to position the window. These windows include menus and tool tips.

The ability to open windows this way needs to be restricted, because it provides a way to spoof windows and deny service by obscuring other windows.

Mechanism: Perhaps X can provide an OverrideOverrideRedirect bit which the WM can set in order to receive all requests to map top-level windows. (Note that X's SubstructureRedirect is a general mechanism that can be used on any window, but it is mostly used for the root window.)

Policy: The WM should position OverrideRedirect windows so that they can only appear immediately above the client's framed windows in the stack.

XSEC_EXIT: When a client has no more top-level windows

Most applications should only be able to run as long as there is a visible indication that they are running. (See "Invisible Background Processes" in "Interaction Design for End-User Security" for this requirement.) These applications should get terminated when their last top-level window is closed. The window manager needs to send a notification to another subsystem when this happens.

XSEC_FOCUS: Input focus

Clients should not be able to set the input focus unless they already have the focus.

Clients should not be able to grab the focus by asynchronously opening top-level windows when another client has the focus.

The XSecurity extension ignores the SetInputFocus request for untrusted clients. Ignoring SetInputFocus might break clients which set the focus to subwindows and expect key events to come from subwindows and not from top-level windows. These clients should probably be fixed to be less brittle.

See also: WM_TAKE_FOCUS mechanism.

XSEC_READSCREEN: Reading screen contents

Generally this should be disallowed. (The ability to read the screen may be granted to special screen grabber clients.)

It is possible to read from the screen in two steps: copy from screen to pixmap, and copy from pixmap to client. One of the two should be disabled by default.

Background colour of "None"

Setting a background colour of "None" is problematic because:

• The contents of other windows can show through, potentially confusing the user. It allows the client to impersonate another, but only to a very limited degree.
• The client may be able to grab the contents of the window and thus snoop screen contents. This is particularly bad if the client can open top-level windows without restriction, in particular screen-sized windows without borders.

The XSecurity extension disallows setting a window's background colour to "None", forcing backgrounds to be black in this case. However, this creates flicker in programs such as Konqueror when scrolling. It seems to be necessary to allow a background colour of "None".

Perhaps the X server could clear a window's background when it replaces another window on the screen but not when content from the same window is being replaced. This would remove flicker when scrolling, but ensure windows have a defined content when initially opened. There would still be some flicker when dragging one window across another.

Uninitialised pixmaps

The X server is not required to initialise the contents of pixmaps. As a result, newly-created pixmaps can contain screen data from other X clients. If the GetImage request is allowed on pixmaps, pixmaps must be zeroed on creation. It is worth zeroing pixmaps in any case because it can be confusing when one application's window contents show up in the window of another X client.

Pointer position

XSEC_PTR_MOVE: Moving the pointer

WarpPointer should be disabled, unless the client has a special permission.

XSEC_PTR_READ: Reading the pointer position

Clients should not be able to find out the mouse pointer's position unless the pointer is inside one of the client's windows, unless they have special permission. This gives the client a way to find out whether the user is using the machine (i.e. whether the pointer is moving), which is legitimate for some programs (e.g. Jabber clients). Without this special permission, xeyes will not follow the pointer.

XSEC_CURSOR: Changing the cursor (pointer shape)

Creating cursors (the X term for the pointer shape) could allow a client to render the pointer invisible, if only while the pointer is over the client's window. Also, we might want to reserve special meanings for pointer shapes that are displayed the pointer is over buttons with special significance. By default, clients should only be able to use stock pointer shapes.

XSEC_CLIP: Clipboard access

A full solution involves trusted Copy/Paste buttons or menu items. A simple solution would be for the window manager to detect presses of Ctrl-C and Ctrl-V (configurable), and give the client write/read access to the clipboard (respectively).

Could have a proxy program that transfers data between the main clipboard and per-domain clipboards.

See PATCH: xace: support for selections.

X selection

The X selection (which by convention can be pasted using the middle mouse button) probably cannot be made secure, because there is no secure path for determining when a selection has been made through a client.

XSEC_DND: Drag and drop

It should be possible for the user to exchange data between X clients using drag-and-drop, using the existing XDND protocol if possible. It should not be possible for a client to initiate drag-and-drop unless the user has taken action to do so. It may not be possible to satisfy that with the XDND protocol. Maybe XDND can be proxied.

It should be possible to transfer authority between processes using drag-and-drop.

XSEC_CONNECT: Setting up X11 connections with suitable authority

With the XSELinux extension, when a client connects to the X server, the server finds the client process's SELinux security context using SELinux's getpeercon() system call. This determines the client's permissions according to SELinux's centralised static policy. Such an approach is not suitable for the object-capability model, which does not label processes.

There are two ways we could set up the connection:

• Weak capabilities: Generate an MIT-MAGIC-COOKIE that the client process can use when connecting to the X server's Unix domain socket. This is how the XSecurity extension works. It provides the SecurityGenerateAuthorization request for creating a new MIT-MAGIC-COOKIE. All processes see the same Unix domain socket but can pass different MIT-MAGIC-COOKIEs.

• Strong capabilities: Client processes are passed different Unix domain socket objects. The MIT-MAGIC-COOKIE mechanism is no longer necessary. Who is responsible for setting up the socket connections? Should this be implemented in the X server, or should there be a helper process which will accept a connection and send the socket FD to the X server?

Do we need to be able to change the X permissions associated with an X11 connection after the connection has been set up?

Responsibilities for a secure X window manager

• Should not allow a client to open a top-level window at the top of the stack unless it already has the focus. Opening a window asynchronously should put the window below the currently-focused client's windows. See AsynchronousWindowOpens for more discussion.

• Handle windows with OverrideRedirect set.

• Securely label clients' windows using their pet names.
• Handle trusted-path key shortcuts for Ctrl-C and Ctrl-V (copy and paste).
• Provide full-screen-window functionality.
• When application's last top-level window is closed, notify to revoke application's ability to run.

We could modify an existing X window manager to add these facilities. This is problematic because there are so many existing window managers to choose from. Which are the most commonly used WMs? Metacity is the GNOME default WM so is probably one of the most commonly used.

Virtualising window management

Suppose we have a proxy window manager. This receives requests to map clients' top-level windows. When it receives window X, it reparents it into window Y, which can have a different WM_NAME property. It passes window Y on to the legacy window manager, which is then responsible for displaying the window's frame.

This arrangement could provide some security properties while using unmodified legacy window managers. However, it is complicated. It is unlikely to work for many of the security properties because many require the proxy WM to know state that is maintained by the legacy WM, and it is either difficult or impossible to mirror that state. However, the idea of splitting WMs into components is important.