[cap-talk] Android using capability discipline

[Fred]

"...misunderstandings and neglect create more confusion
in this world than trickery and malice..."
Security can be lost in different ways but these ways can be
broadly seen as permitting a vulnerability and attacks against that
vulnerability.
An attack need not be malicious.
In the case of a non-malicious attack only ocap discipline is needed
(not an actual ocap).

A key to preventing a vulnerability is to make that vulnerability visible.
If a vulnerability is invisible it really doesn't matter how many eyes
look at it;
this is the flaw in the "many eyeballs" approach to correcting vulnerabilities.
Therefore it is important to construct programs so that every aspect
is comprehensible.
I think this is what is intended in  Marc Stiegler's talk.
Good programming practices naturally reduce vulnerabilities.
If this is true then capability disciple will be applicable on the
Android platform.

What are the interactions of trust?
How is that trust vindicated?

Interactions of trust:
- Between components within an applications
- Between applications sharing a private key (may be in the same process)
- Between applications not sharing a private key
- Between application components not sharing a private key
- Between application components and a non-android process (e.g. service)
In general these interactions use intents.

Given these types of interactions...
How should intents be constructed to avoid sharing more than is necessary?
When should a component be split into multiple components?
(Presumably to isolate/minimize the permission/authority.)
What tools/techniques would make reviews easier/better?

Let me tray that strawman again.

The idea of security reviews is important in using capability discipline.
It would be helpful when looking at a market of applications if it
were possible to certify how "nicely" an application "plays" with others.
certifying applications and components in the security dimension.
Exactly what constitutes "certified" is not completely clear but it would
include things like the cost of performing a security review, whether
the review was done, by who performed the review, and the
results of that review.

C1) Native code circumvents all security constraints and should be discouraged.
There had better be an excellent reason to introduce native code, because
any native code will need to be very carefully reviewed.
Such careful reviews will add cost and increase risk.
Code of this type must be available for public review.

C2) Prefer applications with calls to a "tamed" java/dalvik library.
Applications of this type will not need external review and can be
kept proprietary.
Installation of an application package should check that package for
compliance; similar to the Joe-E verifier.
How difficult would it be to incorporate the tamed joe-e library? and verifier?

C3) "With great power comes great responsibility"
Applications with greater permissions should perform functions
directly related to those permissions.
As a corollary, more sophisticated application (more components)
receive less permissions.

C4) Intents should be provide least access
This is related to POLA.


(Is this the appropriate forum for this discussion or should it be in
an Android forum?)