[cap-talk] Android

[Fred]

Establishing some context here...
My interest is related to developing a market of applications with
a high degree of interaction between applications.

Dan Bornstein <danfuzz at milk.com> writes:

> Fred <phreed at gmail.com> writes:
>> I presume someone has given some thought to object capability on the
>> Android platform.
>
> Hi there. I think about object capability stuff a reasonable amount,
> and I'm one of the tech leads on Android. Android isn't a pure obj-cap
> environment by any stretch of the imagination, but I think it comes
> close enough such that doing "obj-cappy" stuff within an Android
> application could both make sense and be beneficial.
>
> The Android security model treats the process as the unit of trust and
> isolation, and processes are given (what mostly amounts to) an initial
> capability grant, based on an a priori list of permissions that can be
> vetted by the end user (or their trusted proxy). These permissions are
> enforced by the kernel and not by any code running in the app process
> itself. To be clear, a "permission-free" application on Android can do
> a fair bit more than pure computation, but it's a lot less than what a
> typical Unix(-family) process could expect.

It seems that if  the process is taken as an object (as is done in
erlang for example)
then it should be possible to and in ocaps (or process-capabilities perhaps).
However it seems that permissions are granted to applications not processes.
That is every right granted to an application is available to every
process in that application.
This would imply that applications are the ocaps for android.
Did I miss something?

> The existing Android library doesn't make any real attempt to add
> further permission constraints within the process ? for example, the
> vm doesn't come with a SecurityManager installed, and there is even an
> approved and encouraged way to introduce native code into a process,
> so you can always use that to subvert anything the vm might try to do
> ? but as a prophylactic measure (e.g. to help guard against their own
> bugs), individual applications certainly might want to do so.

As is typical adding ocaps involves removing features rather than
adding security.

Anything which violates any of the security constraints needs to have
a thorough security review.
I propose as a strawman the following constraints in a secure android market.

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

C2) Prefer applications with calls to a "tamed" java/dalvik library
These applications will not need review and can be kept proprietary.
This is what was done for Joe-E.
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)  ?
Some system for how permissions are obtained.
* Smaller applications each with a few inherent permissions.
   * a complete system would consist of several applications rather
than just one.
* Larger applications with no inherent permissions.
   * could intents carry permissions from one process to another?