[cap-talk] Capabilities and Freedom vs. Safety

[James A. Donald]

David Chizmadia (JHU) wrote:
> In a pragmatic sense, your situation is akin to the
> case of an evangelical Christian minister discussing
> how to live life as a member of the faithful with a
> group of Muslim imams.

Almost true - except that I have advocated using non
communicable privileges where such are appropriate,
generally for great or durable privileges such as the
authority of a powerbox to read the entire file system,
and write to most files therein, and communicable
privileges where such are appropriate, generally for
small and transient privileges, such as the privilege of
an editor to edit a particular file.

Thus I am more in the position of a tourist to Saudi
Arabia who wants to go to the beach, drink a scotch,
celebrate Christmas, and tour the famous mosques, than
in I am in the position of an evangelical Christian
visiting Saudi Arabia.

I am not the advocate of extreme purity and abstinence
from sin in this debate.

Security must be based on real attacks and real threats,
not on "proofs" of security which have little contact
with reality external to that proof.  Nor can any usable
desktop system be entirely secure - rather the attack
surface can be reduced, and the system can be rendered
reasonably secure, at some cost, against the worst
threats, but not against all possible threats, for there
are a great many possible threats.  Thus "proof" of
security, when applied to desktops, is apt to prove that
which cannot possibly be true.   A particular algorithm
can be secure against a short list of relevant threats,
and can frequently be proven secure against such a short
list.  (Whereupon, as with PKI, the adversary fails to
stick to the list that has been assigned to him.)
Securing a desktop environment is a large and amorphous
problem with an equally large and amorphous set of
threats, thus "proofs" tend to be so detached from
reality as to be strawmen.  One example of such a
strawman being the prospect of capabilities as data
so durable as to be compiled into a program image.

The correct approach is that taken in Bifrost, which
enumerates numerous specific concrete real world
attacks, by realistic adversaries, and takes a wide
variety of concrete measures that will be effective
against all or most of those attacks, or will
substantially reduce the prospect of those attacks, even
when they cannot be entirely eliminated.  Among those
measures, are the use of communicable privileges, to
make drastic limits on ambient privileges workable.  But
ambient privileges are present in Bifrost. Communicable
privileges in Bifrost are necessary because ambient
privileges are for the most part severely limited, not
because they are entirely absent.

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.

It is certainly true that for communicable permissions
involving a single user on a single computer,
"protected" capabilities - privileges that are simple
unprotected data a ring<3 (OS code), but at ring 3 (user
code) are not data, but relationships with the operating
system, are apt to be simple, efficient, and provide
provable security against certain types of error or
defect in ring 3 code - protected capabilities are the
most useful and best for many valuable tasks.  One
should not however conclude from this that everything in
the world should be rewritten in terms of protected
capabilities, for the provable security they provide is
provably secure against the least of our problems.

I doubt that rewriting everything in terms of protected
capabilities is a good idea, and I am sure that even if
it is a very good idea, as many on this list have
plausibly and passionately argued, it is not going to
get done.