[cap-talk] Selling capabilities programming

[James A. Donald]

"Stiegler, Marc D" <marc.d.stiegler at hp.com> wrote:
 > Your own capabilities to your own documents should be
 > as durable as the documents. Silly to do otherwise.

No capability should be durable if it can be avoided,
and for capabilities to documents, can be avoided.

If it has to be durable, should be an ACL, a permission
associated with a particular object, not a communicable
permission.

Permissions that need to be durable (need to last longer
than any program invocation) seldom need to be
communicable, and permissions that need to be
communicable seldom need to be durable.  Permissions
that need to be both communicable and durable are a
security problem.

When the operating system boots up, capabilities system
does not exist, so the the ring zero code can do
anything.  When it launches normal programs, it gives
them capabilities that will last at most as long as
those programs last. An ACL gives the document editor
permission to invoke a file selection powerbox inside a
frame that identifies that particular invocation of the
document editor.  The document editor invokes a file
selection powerbox, which can browse the file system
because its ACL permits this, and can issue file access
capabilities because its ACL permits this. The file
selection powerbox issues a capability, a communicable
permission to access a particular file to the particular
invocation of the document editor, a capability whose
session lifetime is limited by the lifetime of
particular invocation of the document editor, even if
subsequently passed to other programs.

At boot time there should be no capabilities, and
capabilities created during operation should always have
inherent limits on their session lifetimes - each
capability should be associated with a program instance
and incapable of enduring when the program is closed.