[cap-talk] Selling capabilities programming

[James A. Donald]

Sandro Magi wrote:
 > As you say, it is true that if two programs can
 > communicate, they can share all their capabilities, or
 > proxy all data, but maximally co-operative/conspiring
 > programs aren't the only cases of interest.
 >
 > Consider a malicious program P that issues a known
 > exploit against a widely shared service S; this
 > exploit returns a memory dump of S to P. With CAD, P
 > obtains all of S's capabilities.

In the wild, often the objective of an attack is to
obtain data - marketing data, credit card numbers,
passwords, and so forth.  I have never heard of an
attack happening in the wild that obtains data by means
short of getting the attackers code, script, or commands
executed by the targeted system.  Doubtless some such
must exist, but they are not common.

A security measure that protects against a rare and
almost unknown attack, without protecting against the
common attack, is not very interesting.

"Proofs" that protection significantly change the
security characteristics of system consider the case of
extremely durable shared secrets - which is to say,
secrets used badly.  A fair comparison is to compare
secrets used badly with "protection" used badly.

Most exploits cause the buggy program to fail in a way
that executes code of the adversary's choosing.  A
typical exploit is a buffer overrun, where data in the
buffer winds up being executed as assembly code or
trusted script.  Most web server exploits cause script
of the attacker's creation to be executed at the highest
privilege level, or executed with the privileges of the
registered user under attack.

Most attacks are active and one way.  The attacker sends
a lot of data to the attacked program.  He gets little
if any data back until he gets control of the attacked
program, if then - at which point it matters little if
he uses that control to exercise capabilities, transmit
capabilities through "authorized" channels, or transmit
them through unauthorized channels.

Capabilities as data significantly increase the attack
surface only if they are durable and widely shared
secrets, such as credit card numbers or social security
numbers.  It has long been known that a widely shared
secret is a contradiction in terms, hence the saying:
"What one man knows, nobody knows, what two men know,
everybody knows."  Similarly, it has long been known
that widely shared secrets must be transient - in
Shakespeare, the commander sets the password for the
day.

All high and durable privileges are security flaws.
Communicable privileges mean we can get by with less of
them - less security flaws, not no security flaws.

The advantage of communicable privileges is that they
can be small and transient, which means that in
practice, in a system that employs both communicable and
non communicable privileges such as ACLs, communicable
privileges generally *will* be small and transient,
which means that in practice attacks on communicable
privileges are unlikely to be the major attack surface,
hence armoring up this low priority attack surface
against a low probability attack is not a goal that
should be given high priority compared to other goals.

If communicable capabilities are usually transient and
minor, as they should be, then discovering secret
capabilities are a minor problem - the big problem
remains attacks on privileged processes with non
communicable privileges.  The advantage of communicable
privileges is that we can get by with less processes
with high privileges.  Instead of issuing a general
privilege to access all files to all programs, we issue
a specific privilege to one piece of code to access all
files, and that code issues transient communicable
capabilities to access particular files.

Certainly protection should be employed when the costs
are low, and it is reasonably practical to do so, but it
does not change the provable security characteristics of
the computer, except in the case of threats that involve
the passage of time considerably greater than the
invocation of particular programs, as in the straw man
example where a durable capability as data is embodied
in the program executable.  That is a straw man case,
for no one should implement a protocol in which data
that grants privileges has duration such that it is
practical for it to be embodied in executables.
Privileges that endure substantially beyond the lifetime
of particular running instances of programs should
generally not be communicable where this can be avoided.
One case where it probably cannot be avoided is logon
capabilities - but protection does not help us there -
indeed there is no entirely satisfactory solution,
though some solutions are considerably better than
others.  And even in that case, no one is ever going to
have a protocol in which secrets are so durable that it
is practical to embed communicable privileges, such as
logon password, in the body of an executable file.