Authorizing copy and paste operations

[Gigasoft]

I'd like some ideas on how to make sure that the clipboard is only accessed with the user's authorization, while at the same time not making the act of copying and pasting needlessly cumbersome. For example, it would be bad if a rogue application could secretly listen in on everything the user copies to the clipboard and send it off somewhere, but I'd also like to avoid prompting the user if he really, really sincerely wants to paste every time.

A solution that sort of works would be to mark the process that owns the window that has the focus as being authorized when the user presses a standard key combination (such as Ctrl+X, Ctrl+C, Ctrl+V) or chooses a clipboard-related command from a menu (which has a system-imposed icon, text or other distinguishing mark), until the next time another program changes the clipboard content. But, some programs might want to have multiple means of copying or pasting, each with different shortcut keys, such as a graphics program which lets you paste into an existing image with or without transparency, or as an entire new image.

Furthermore, should I worry about someone making a sneaky game that uses a control scheme where one, for example, jumps with Ctrl and shoots with V?

[bzt]

Hi,

Let's see if I understand this right.
1. you have functions to access the clipboard (CopyToClipboard(), GetClipboardData() etc.)
2. applications can call these functions
3. the user can use shortcut keys and menus that would ultimately lead to call of these functions
4. normally an application should only call these functions when the user initiated the operation

So in short, you want to check if clipboard was really accessed by the user, and it should only work on real user input.

I see two options here:
1. use a token.
When the user initiates a valid operation (shortcut, menu etc.), set a security token, unaccessible by the application, that the clipboard routines check for. Then an application can only call clipboard if there's a token, otherwise those functions just return empty handed.

2. forget about the whole thing, and turn it up-side down.
Don't allow applications to access the clipboard. Instead implement GetSelection() and PasteClipboardData() in each application, called by your GUI when user uses a valid operation. With other words, implement c'n'p the other-way around: applications do not access the clipboard, the clipboard calls hooks in the apps.

Cheers,
bzt

[Qbyte]

Clipboard operations should be entirely handled in user space, meaning that the application decides what combination of keys (if any) results in data being copied or pasted from the clipboard (via to_clipboard() and from_clipboard() system calls), not the operating system, display server or window manager. That gives the most flexibility.

If you have a sensitive application, that application could simply not copy to the clipboard in certain instances (like when in a password field, etc) or it could use its own local clipboard that no other applications have access to instead of the global clipboard.

If you want to restrict access to the clipboard, your kernel can implement a flag within the task_struct that determines whether a process can access the clipboard or not which it checks each time it gets a "to_clipboard()" or "from_clipboard()" call, so that untrusted applications can be excluded from it.

[bzt]

Clipboard operations should be entirely handled in user space

Yes, but on the application side or the GUI side, that's the question.

meaning that the application decides what combination of keys (if any) results in data being copied or pasted from the clipboard

This can be done also via a set_keyboard_shortcut() call to the GUI, or via some resource file describing the application menu like Windows does.

If you have a sensitive application, that application could simply not copy to the clipboard in certain instances

I think this is not what the OP is worried about. He wrote "it would be bad if a rogue application could secretly listen in on everything the user copies to the clipboard", and applications not using the clipboard at all is not a really viable option imho.

it could use its own local clipboard that no other applications have access to instead of the global clipboard.

How should a string be copied from one application to another then? Like I select an url in a document, press copy, then I switch to the browser and press paste there?

If you want to restrict access to the clipboard, your kernel can implement a flag within the task_struct that determines whether a process can access the clipboard or not which it checks each time it gets a "to_clipboard()" or "from_clipboard()" call, so that untrusted applications can be excluded from it.

This is less secure implementation of the token algorithm I suggested, but generally yes, that's the idea.

Also consider my other suggestion, turning this upside down by removing the need for listening to clipboard:
1. an application sets up shortcuts for copy'n'paste in the GUI (or window manager, etc.) using register function of resource files
2. the application also provides hooks for copy and paste
3. when the GUI (or wm) detects the user input, it calls those hooks in the focused app, and strictly in the focused app only
4. there's no listening on clipboard (which is GUI (or wm) initiated now), so no rouge application can't secretly capture the clipboard buffer

Cheers,
bzt

[Qbyte]

Yes, but on the application side or the GUI side, that's the question.

Well, that depends on the design of the GUI library. Some opt to provide a keyboard listener/callback interface, while others will leave it to the programmer to implement their own keyboard input handlers. I personally prefer the latter, because the former tends to associate with Inversion of Control designs which I don't like (such as GTK where it essentially hijacks your main function).

How should a string be copied from one application to another then? Like I select an url in a document, press copy, then I switch to the browser and press paste there?

This can be handled by having a standardized clipboard string format. When an application copies a string to the clipboard, it must ensure that it is in the standard format (which could just be a simple null-terminated c-string for example). Another solution is to tag the clipboard data with the process id (or name) of the process that copied the string to the clipboard, so that the process that receives the data with the "from_clipboard()" call knows what process uploaded it so that it can use the format specific to that process.

This is less secure implementation of the token algorithm I suggested, but generally yes, that's the idea.

It's actually more secure because the system can directly control whether or not a process can access the clipboard at all, and the user can view and modify this property via the task manager. Whereas with your token scheme there could be vulnerabilities (like fudging inputs or if the user performs an enabling action that the rogue application can exploit).

Also consider my other suggestion, turning this upside down by removing the need for listening to clipboard:
1. an application sets up shortcuts for copy'n'paste in the GUI (or window manager, etc.) using register function of resource files
2. the application also provides hooks for copy and paste
3. when the GUI (or wm) detects the user input, it calls those hooks in the focused app, and strictly in the focused app only
4. there's no listening on clipboard (which is GUI (or wm) initiated now), so no rouge application can't secretly capture the clipboard buffer

That has the major downside that it removes the ability to have trusted applications which depend on listening for their functionality (eg, a daemon that buffers all data copied to the clipboard) so I don't see that as viable. A simple flag that controls whether a process can access the clipboard and the option to restrict access only to processes which have the focus is the best way to do it, because it retains maximum program flexibility while still solving the problem.

[Schol-R-LEA]

Perhaps we should start with a few more basic questions about how things are handled already:

• What sort of security architecture(s) does your OS use overall, if any, and does any part of it allow configurable policy? In particular, have you considered a capability-based architecture (which would simply make clipboard access a capability which could be passed to a process and possibly rescinded by the system later - basically, a more general version of the token-passing option bzt mentioned)?
• How does your OS expose interrupts and/or system messages to the applications?
• Do you have any sort of system callback mechanism in place (i.e., where an application can pass callback hooks to the OS, which allows the OS to call on the applications' functions directly, rather than vice versa)?
• Is your GUI in userspace, or part of the kernel, or some combination of those? Is there a separation of concerns (as outlined in Graphics stack) and how is it organized? Are their separate widget library, window manager, and desktop environment components (as with most Linux and *BSD GUIs, most of which are built on several separate layers - X Window System or Wayland for basic graphics; Mesa for 3D rendering; Motif, GTK, Tk, ELT, or Qt for widgets; Cairo, HarfBuzz and Pango for fontology and other vector-drawing operations; Compiz, xfwm4, Marco, Weston, or Compton for compositing; etc.) or ), or is it more monolithic (like MacOS and Windows - though Windows does have some ability to swap out the DE, even if it is a real pain to do)?
• Does the system have a single universal clipboard, or does it allow applications to spawn local clipboards separate from the system-wide one? If the latter, is their a way to pass clipped items from a local clipboard to the global one, and how would you specify that?
• Have you considered a more general editing history facility (something like a kill ring or an edit stack) instead of a simple clipboard? If you have, how would you expose the items not at the top (presumably, the familiar CUA operations would be LIFO by default, but you could allow the 'stack' to be re-arranged or bypassed in some way separate from those)? This is common for image editors like Photoshop or GIMP, but few user environments support it system-wide.

[bzt]

@Schol-R-LEA: a big +1 to what you've said.

it could use its own local clipboard that no other applications have access to instead of the global clipboard.

This can be handled by having a standardized clipboard string format.

You misunderstood, it's not the format I was asking about, but how to get that string in the first place if "no other applications have access".

It's actually more secure because the system can directly control whether or not a process can access the clipboard at all,

You misunderstood again, this is exactly the same with my solution. The only difference is, your solution uses a single bit, while mine uses a token match. Neither your bit, nor my token can be accessed by the process.

Checking for a bit in general is less secure than matching a random value such as a session id, simply because a bit has two states (50% chance to get the right one at first), while with a token you have only 1 in a 2^32-1 chance (approx. 0.000000001%).

Cheers,
bzt

[max]

I‘d provide a clipboard API that is accessible to any program, but I would ask the user the first time a program tries to access the clipboard. After all it‘s mostly a feature relevant in UIs and a popup wouldn‘t hurt. Also the system programs should be allowed by default so you have a set of trusted applications.

[Gigasoft]

To be clear, my problem is not about the technical implementation in terms of how the system communicates with the application, but is rather an user interface design issue (determining what, exactly, should constitute a valid clipboard access command).

What sort of security architecture(s) does your OS use overall, if any, and does any part of it allow configurable policy? In particular, have you considered a capability-based architecture (which would simply make clipboard access a capability which could be passed to a process and possibly rescinded by the system later - basically, a more general version of the token-passing option bzt mentioned)?

Each process has a set of handles which contain an object pointer and a 32 bit access mask, whose meaning depends on the type of object. I am also planning to implement indirect handles, such that when placed in the handle table, will be automatically followed when accessed, but not when duplicated, thereby providing a revocation mechanism. There is no concept of ACLs and no global namespace for applications to access. There will be some sort of mechanism for storing permanent policies, but the details are not decided. A policy for running a program will presumably include a set of paths (relative to a set of paths provided by the invoker) with access masks which can be used to access devices, directories or files, as well as various other privileges. Of course, one could use this to disable clipboard access entirely, but that should be a last resort.

How does your OS expose interrupts and/or system messages to the applications?

UI threads receive all their input from an input queue. Each window is associated with a particular input queue. The application receives a message if a message has been posted to the queue or a window needs to be updated. Messages can contain an object pointer, which when retrieved by an user mode thread is turned into a handle. Another function, which is in turn called to handle a message, constructs an object that wraps the passed handle and invokes the target window's message handler. Mouse input is only passed for the client area of a window. The title bar, borders and menu bar are considered part of the frame, and are handled by the system. Popup menus are system windows, associated with the same queue as the owning window. Messages directed at system windows are handled automatically if found when an user mode thread wants a message. At some point, this will probably be extended to allow for messages directed at other things besides windows.

Is your GUI in userspace, or part of the kernel, or some combination of those? Is there a separation of concerns (as outlined in Graphics stack) and how is it organized? Are their separate widget library, window manager, and desktop environment components

The window manager is part of the kernel. Controls are currently implemented by having the window's message handler subdivide the window into subviews and passing input to the appropriate target, without the system's involvement. An abstraction is provided called a "view", which can represent a window or a subview, and has an associated handler. Standard controls can be employed by user mode applications as well as the system, and the code then runs in user mode or kernel mode, respectively. In the future, I intend to implement child windows too. The desktop environment (what little there is of it) is currently part of the kernel.

Does the system have a single universal clipboard, or does it allow applications to spawn local clipboards separate from the system-wide one? If the latter, is their a way to pass clipped items from a local clipboard to the global one, and how would you specify that?

There is only a single global clipboard (per logon session). No standard mechanism is currently planned for having application clipboards. If only needed in order to avoid unnecessary copying of data, one could have the system automatically request the data from the application when the user tries to paste it into another application, thus providing a seamless experience for the user. If an application implements its own type of clipboard-like feature, it would need to implement a method for selecting the internal clipboard as a source or destination for operations. An alternative method of initiating clipboard transfers would be via a drag and drop interface. In this case, a system-defined area on the screen could serve as the drag and drop source or target corresponding to the clipboard, and one could even allow for additional clipboard slots in this way.

Have you considered a more general editing history facility (something like a kill ring or an edit stack) instead of a simple clipboard? If you have, how would you expose the items not at the top (presumably, the familiar CUA operations would be LIFO by default, but you could allow the 'stack' to be re-arranged or bypassed in some way separate from those)? This is common for image editors like Photoshop or GIMP, but few user environments support it system-wide.

I haven't spent much time thinking about the details, but if we have a set of stack locations represented by subsections of the system screen area, one could rearrange them by simply dragging them. It's definitely on the to-do list.

Anyway, after having thought about it for a bit, here is what I am currently leaning towards for the original problem:
- Reserve a key on the keyboard (for example, the Windows key or the Menu key) such that the application will not receive input events for this key or any key combination involving this key. Instead, such key combinations will solely be used to activate menu commands or other special functions, such as clipboard operations.
- Clipboard operations can be activated by standard shortcut key combinations, possibly involving additional shift keys, which will be passed to the application. They can also be activated by selecting special menu commands whose text will always begin with the word "Cut", "Copy" or "Paste".
- If a clipboard operation key shortcut is entered or a clipboard command is selected on the menu, a clipboard handle will be passed in the command message. If a Paste operation is initiated, any previous write access is revoked.
- When the clipboard is written, any previous read access is revoked.
- Clicking inside a window, dragging the cursor inside a window belonging to another application and releasing it will allow the first application to generate a block of data which will then be transferred to the second application, if support is indicated by the applications.