Imagine that you have let a strange person (program) into your machine that claims to edit flat ascii files for you in an especially convenient manner. We will call him the servant. You would like to try his services before deciding whether to trust him with your family jewels (files). If his service is inadequate then there is no dilemma. The servant appears as a largish icon of a man wearing a mask. The mask is a system imposed feature indicating that there is no certificate vouching for the servant.
The servant has his ungloved hand out with "file" written just under it. (That the hand is ungloved is another system imposition. Had it been gloved you would have known that any access given to him could produce no side effects, such as writing the file.) That means that the servant wants to be able to read and write some file. You have a file with no significant secrets but you don't want it trashed. You duplicate it and move the icon for the duplicate to his hand. He puts out his hand again. He wants a screen window thru which to cooperate with you concerning the file contents. You click on a screen icon indicating that you want a new window. That results in a new small square window that you move to his hand. The square grows and the file contents appear there. The masked man is still on the screen and his icon is clearly attached, somehow, to both the file and the window.
You attend to the window for a while. If you don't like the behavior you can banish the masked man, the duplicate file and the window. You know that no harm has been done.
The harder task comes when you decide that you want to hire the servant.
It should be easy to determine ramifications of one’s past access relevant actions. This is a function that is not supported by the kernel but can be supported at a higher level. If a program sends a capability to another program it is not feasible nor generally necessary to log this fact. If I (a user) send a capability to some general object then this action must probably be logged. Perhaps all such actions must be transformed into rescindable actions. This is just to get to the situation that conventional systems purport to provide such as displaying the permissions on a Unix file. Further function might report the fact that mutable object X has had access to secret information.
Preestablished compartments can alleviate much of the clutter of such reports when it is not necessary to understand the security perimeters within the compartment.
In order that it is unnecessary to log messages between application components it is necessary that they run within a membrane of some sort. It might be OK to give an application the authority to make these changes but then they must be logged.
Access to the content of the clipboard is problematic. In the very few systems where I have seen the rules it seems that any running program can read or write the clipboard at any time. Here are some capability style rules for access to the clipboard.
There is one clipboard for the screen. When splat C is typed on the keyboard a signal is sent to the program that produced he image over which the mouse cursor sits. The message contains a resume key (one shot continuation) which may be invoked with new clipboard contents. If the cursor moves away from the image before the continuation is used, the continuation is revoked. When splat V is typed on the keyboard a signal is sent to the program that includes the current clipboard contents. No other access is provided.