[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Thu, 26 Oct 2006 00:45:18 +0200,
Marcus  wrote:
> In my reply to Charlie I give an example based on the L4 kernel design
> where I motivate the distinction I am making above between authority
> and life-time.  Even if you want to reserve the concepts of identical
> authority and rights for co-equal capability copies, I think the
> distinction can be generally useful in analysis (I am open to
> suggestions on terminology).

Specifically, the life time of a capability object is also bounded by
the life time of the capability page that the capability is stored in.
We tend to ignore this, because that storage life time usually bounds
the life time of the whole process as well.

However, in the system designs I am currently interested in this is
also true for most capabilities (ie, capabilities and storage come
from the same party, the parent process).  There are also other types
of capabilities in these systems, but for those I try to make an
argument that durability is not important (an example is found in my
reply to Charlie).

Such system designs make the capability, trust and storage hierarchy
mostly coincidential, with some lateral, temporary exceptions.  Of
course the design of such systems is strongly motivated by the L4
design itself.  One such project is for example Bastei at the L4 group
in Dresden (rumors about that on http://os.inf.tu-dresden.de/~nf2/)

I should also mention a limitation.  Such systems do not easily
support confinement+isolation at the same time, as the opaque storage
provided by the EROS space bank and used by confined constructors
does. It is not out of question to build such respective services on
top of that, potentially breaking with some of the design principles,
but I have not studied that thoroughly.  The lack of this feature
which some of you may consider to be essential to implement certain
security policies may puzzle you, or cause you to reject these
systems, but I until proven otherwise I believe it is mostly a matter
of different priorities and design goals in the various projects.

Hopefully this background info sheds some light on the discussion.

Thanks,
Marcus