Trusted-path buttons in a secure window system
Contents
Introduction
In a secure window system there are a number of actions that we might want to occur only when the user takes an action. For example:
Opening new top-level windows (see AsynchronousWindowOpens)
- Copying data to and from the clipboard
We don't want processes to be able to carry out these actions without a request from the user.
Processes would have to declare, in advance, regions of the screen that act as trusted-path buttons.
When the user clicks on a trusted-path button, the window system does two things:
- sends a message to the process that created the window
- sends a message to the subsystem that deals with the trusted-path action, e.g. the window manager (for window opens) or the clipboard manager (for copy/paste)
Appearance of buttons
In some cases the appearance of a trusted-path button will be defined by the trusted subsystem, while in other cases the untrusted process will be allowed to render the button itself.
- Window-open buttons can be rendered by untrusted processes. The purpose of making opening a window a trusted-path action is to limit the rate at which windows can be opened and ensure that windows are only opened at predictable times (i.e. when the user clicks the mouse).
- For clipboard buttons there is a greater case for having a fixed appearance supplied by the clipboard subsystem. While opening a window is reversible (by closing the window that was opened), pasting data from the clipboard to an untrusted process cannot be reversed because the process may leak the data (perhaps through covert channels!). It is therefore more important to forewarn the user that they could cause a Paste action to happen.
Pointer shape
The pointer might change shape when over a trusted-path button to indicate the action that the button carries out. This would mean that processes would not normally be allowed to define their own pointer shapes (see XSEC_CURSOR on X11SecurityRequirements).
Spoofing
We cannot prevent processes from rendering things that look like trusted-path buttons but aren't. Processes can render any images into their allocated regions on the screen. This should not be a problem: clicking on such a button will not carry out a trusted path action. The purpose of trusted path buttons is to alert the user when a trusted-path action can occur, or to bound the rate of trusted-path actions.
Mechanism
The mechanism for setting up a trusted-path button could be to declare a whole subwindow (i.e. an X window) to be a trusted-path button. Pointer events on the button would be handled by a trusted component (perhaps the window manager). Expose events might also be handled by the trusted component.
There is the possibility of using InputOnly windows under X for client-rendered buttons.
Trusted-path key bindings
It should also be possible to invoke trusted-path actions via key presses.
- Clipboard actions should be bound to keys chosen by the user not by the process. (Typically the shortcuts are Ctrl-X, Ctrl-C and Ctrl-V.)
- Window-open actions can be bound to keys chosen by the process. This means that a process would have to declare some its key bindings to the window system.
Related work
The EROS Trusted Window System proposes using trusted-path buttons for clipboard Copy/Paste buttons. (It does not propose anything similar for opening top-level windows.)
CapDesk's "power bar" has a similar purpose, but is less general. It provides a toolbar containing trusted-path Cut/Copy/Paste buttons. CapDesk processes cannot lay out the buttons separately.