[cap-talk] Capabilities and Freedom vs. Safety

[James A. Donald]

David Chizmadia (JHU) wrote:
 >   * An ocap design solution can be found for nearly
 >   all enforceable
 >     security problems;

We have had this same discussion and the analogous claim
about Erlang's concurrency, and long ago we had it
regarding object oriented languages where everything was
part  a single inheritance hierarchy descended from the
class "object".  A similar argument is made concerning
every bright new idea in programming, and the same
discussion follows.

Any turing machine can emulate any other turing machine.
Thus when someone has a good idea that provides a clean
and elegant way to express solutions to an important and
interesting class of problem, he or his disciples are
apt to make the unsurprising discovery that his good
idea can, with suitable contortions and elaborations,
solve *every* problem, much as one can build any circuit
out of nand gates. But it never seems to happen that the
rest of the world is inclined to go through those
contortions and elaborations.

Object capabilities are a good fit to some problems, and
a poor fit to others.  Programmers will never be
inclined to use them for problems where they are a poor
fit, even where such use could potentially benefit other
people who are checking the first programmers code for
certain classes of security problem, for they do not
benefit the first programmer writing the code.

Microsoft's IDE, when it creates the skeleton of a
project, creates a single huge class with a single huge
object "theApp" which is globally accessible, and
contains as global variables everything the software
needs, massively violating the data localization goals
that were the objective of object programming.

Similarly, if Microsoft was an object cap programming
environment, all the capabilities objects would be
initialized at startup to the extent that this was
possible, and stuffed into the "theApp" object, where
all their capabilities would be ambient to all the code,
with the result that all the advantages of writing
programs in a purely object capability language would be
eliminated.

 > On the other hand, the ocap community is attempting to
 > displace a firmly entrenched ACL community that has an
 > overwhelming economic incentive to ignore any real
 > solution to the problems from which they derive
 > profit. As a result, the ocap community is held to a
 > much higher standard of "evidence" than the ACL
 > community. The main reason that so many people on this
 > list use the word "proof" (or "prove") is that our
 > experience is that we can't even be *heard* unless we
 > *prove* that ocaps are better than ACLs.

But since any turing machine ...  any such "proof" is
invalid.

What you *can* prove is that anything you can do with
ACLs, you can do with ObCaps - but that proof fails to
address, cannot address, the issue of whether you are
more likely or less likely to do so correctly, and
produce a user interface that makes the resulting system
apt to be used correctly.

Proofs of security can only be made in very simple
cases.  Typically you assume cryptographic algorithms
have certain properties, and then you prove that a
protocol built from these algorithms has certain
properties.  As the system gets larger the proofs get
weaker.  We find we are making increasingly questionable
assumptions about the algorithms, and assuming an
implausibly cooperative adversary.   A desktop
environment is not the kind of thing one can produce a
genuine proof of useful security, for such environments
fail because stuff that could have been done was not
done, or was done wrong, and you cannot prove that it is
going to be done, and done right.

 >> For every kind of privilege, we need a system for
 >> providing, limiting, and restricting that privilege
 >> that is best suited to facilitating rightful uses of
 >> that privilege, preventing wrongful uses of that
 >> privilege and protecting against realistic attacks.
 >> The system necessarily depends on the case, requiring
 >> a multitude of systems.  One size is unlikely to fit
 >> all.

 >     I've interpreted the above paragraph to make the
 >     following
 > assertions - none of which I have any problem
 > supporting:
 >
 > 1.  A powerbox is needed for each privilege; 2.  The
 >     powerboxes for different privileges may be different:
 >     specifically, they may enforce different policies
 >     for providing limited or restricted privileges
 >     derived from the original privilege to other
 >     software in the system;
 > 3.  There exists a mechanism for enforcing the
 >     limitations and
 >     restrictions embodied in the derived privileges
 >     distributed by the powerbox.

A powerbox is a user interface for designating entities
and granting permissions to access them.  For a lot of
privileges, we don't really want a user interface, so
the concept of "permission" is rather misleading.   Some
things come forth from the operating system equipped
with some divine right, and never discuss it with the
user or system administrator at all.  Hence "privilege"
is the better term than permission in these cases.
As I posted earlier:

: :	Programs should be installed by a highly
: :	privileged install script interpreter which
: :	interprets untrusted scripts provided with
: :	the program - scripts that are normally
: :	written with the good of the user in mind,
: :	but could be written to attempt to install
: :	malware or trojans.
: :
: :	The install script interpreter constructs an
: :	uninstall script guaranteed to successfully
: :	uninstall the program, by default leaving
: :	behind program configuration information, and
: :	data stored by the program after
: :	installation, but removing all originally
: :	installed code and data and all permissions.
: :	Install scripts are untrusted, uninstall
: :	scripts are trusted.
: :
: :	Packages should be installed in a program
: :	directory that *only* the install script
: :	interpreter has general write access to.
: :	User cannot delete stuff, except by
: :	uninstalling, cannot modify stuff, cannot
: :	even browse the directory except by viewing
: :	the uninstall list.
: :
: :	Every installable package, every group of
: :	programs with a single install, gets read
: :	access, optionally write access, to its
: :	program's directory in the program directory,
: :	but no others in the program directory,
: :	cannot even browse them.  The install script
: :	for a package can grant other installed
: :	packages access to its own directories, (and
: :	discover that the other package does not
: :	exist if it gets an error) but cannot grant
: :	its programs access to another package's
: :	directory.  Running programs can discover
: :	what packages have given them access, but
: :	cannot discover what other packages exist.
: :
: :	There are per user directories, the
: :	equivalent of unix home and Microsoft "My
: :	documents" which are created when a user is
: :	created, and per user and program combination
: :	directories, which may be created (if the
: :	install script requests that this be
: :	authorized) when a program is first run by a
: :	particular user, the equivalent of
: :	Microsoft's "application data" directories.
: :	There is also a "shared documents" directory
: :	that all users can read from and write to,
: :	and an analogous "application data"
: :	directory.  There is a "my public documents"
: :	directory that all users can read from, and
: :	only each particular user can write to.
: :
: :	Most programs can only read from or write to
: :	"my documents", "shared documents", and "my
: :	public documents" and so forth through a
: :	powerbox, but they can read and write their
: :	particular directories at will.
: :
: :	You will notice two things about this
: :	description:  One is that the user will never
: :	have strong need to set or modify
: :	permissions, so we do not much care how
: :	horrid the user interface is for modifying
: :	them.  (None of the evils of Polaris.) The
: :	other is that all of the permissions
: :	described are durable, and none of the
: :	permissions described are ever intended to be
: :	communicated.  The natural language
: :	description of this system is terms of privileges
: :	belonging the entities, ACLs.

 > It would be instructive for all of us if you could
 > state the top 20 problems that you perceive.

As all problems intermingle and overlap, there is no one
top twenty, since each problem manifests under many
headings, and contributes to many headings.

  1.  Logon - this includes such diverse problems as too
damn many passwords, phishing, the problem of accessing
files shared over a network, and the problem of
continuity of identity in file sharing networks.

2. Malware, viruses and trojans.

3. Denial of service attacks.

4. Excess authority for web pages in the browser and for
scripts in email messages.

These problems intermingle, as viruses are spread by
fraudulently assuming the identity of your bank, and
malware is used to circumvent clever logon solutions, as
in the continuing attack on E*Trade's logon, which has
caused serious losses in the share market.  People use
deliberately failed logons to deny service to other
people, as for example in bidding wars on Ebay, where
one bidder would lock other bidders out of their Ebay
accounts, until Ebay gave up its policy of locking your
account after multiple failed attempts, thereby allowing
people to launch online dictionary attacks against Ebay
users in order to steal their reputations using multiple
zombie PCs in order to avoid being traced.

The finer you slice them, the more one problem is part
of another problem.