[cap-talk] Selling capabilities programming

[James A. Donald]

David Hopwood wrote:
 > In the language case, the major impact on an
 > implementation of using password/sparse caps as
 > opposed to protected/partitioned caps, is that the
 > former precludes precise GC. This is because there's
 > no way for the system to trace all of the capabilities
 > possessed by a domain or to determine whether a given
 > bit pattern is a capability -- which is the same
 > reason why password caps have weaker security
 > properties.

Tracing all the capabilities possessed by a domain is
significant overhead and complication - and if a domain
consists of a user and a substantial set of networked
computers that are the private property of a particular
user, may well also be a violation of privacy and a
security threat against the user.  Also very hard to do
when everything is networked directly to everything
else.  "Tracing all the capabilities possessed by a
domain" seems to presuppose some kind of star topology,
which is natural and easy on a single machine, indeed
almost unavoidable, perhaps the simplest way to do
things, but today, even windows are networked.  Sounds
like a hard problem, and I do not want to even think
about hard problems if I can avoid it.

I am sure that there is a good case that it would be a
really good thing to solve this hard problem, and I am
sure you have a really neat solution, but do not see any
urgent use case for solving it.  There are lots of
urgent problems for which we have solutions, yet have
not successfully delivered those solutions to end users.

If it is possible to know all the capabilities possessed
by a domain, then bad guys can know all the capabilities
possessed by a domain.  To ascertain whether this is a
good thing a bad thing, or a vitally necessary thing,
need actual customers making actual use of the system.

Suppose we use an editor to edit config.ini.  One hazard
is that the editor might leak the privilege to edit
config.ini to some malware program, quite likely leak
the privilege by leaving it in some memory location that
does not get overwritten - but presumably the capability
to edit config.ini only exists until we close the edit
window, whereupon the editor should free it, so a more
likely hazard is that the editor will be provoked to
alter config.ini in some improper way, perhaps due to a
trojan horse macro that watches for the user editing
crucial system files - Jed's "cooperating conspirators"
- that the editor will leak the file handle is the less
likely hazard.

There is a risk with all these clever ideas for
providing secure solutions that one will define the
"correct" solution as one that implements *all* the
clever ideas - which may well be rather onerous,
particularly if too many people have too many overly
clever ideas - the notorious project lead on crack
problem.

Rather a correct solution is one that implements what
the user most needs, and is forwards compatible with
implementing all these other clever ideas as and when
they are needed, for those cases where they are needed.