downloaded code complexity issues

[Peter Firmstone <ji...@zeus.net.au>]

Some ideas for discussion:

What are the main concerns with proxy codebase security?

   1. During deserialization, untrusted code is given a thread, also if
      untrusted classes are loaded, static initializers are run, this
      occurs even before deserialization.

What can untrusted code do?

   1. Hold class locks, causing deadlock. - Denial of Service.
   2. Cause stack overflow errors and out of memory errors.  - Denial of
      Service.
   3. Steal information and send it back to the proxy server during
      deserialization.

How can you prevent class loading untrusted code? 

   1. Require DownloadPermission by default.
   2. Use Secure Discovery, the lookup service is authenticated prior to
      class loading the proxy, this doesn't require DownloadPermission.

But it's not quite that simple, limitations:

   1. You must trust the signer of the proxy codebase prior, in order to
      grant DownloadPermission.
   2. X.509 is complex and still has some remaining unsolved security
      issues.
   3. X.509 doesn't have a global name space, Certificate Authorities
      have separate name spaces that aren't unique.
   4. http://en.wikipedia.org/wiki/X.509#Security

Can we avoid the need for signed codebases and X.509 Certificates?

What about FindBugs and other static analysis tools?

   1. FindBugs service (reflective proxy, to avoid codebase download),
      the client can set an acceptable bug ranking locally
      (configuration), then send codebase annotation strings to the
      FindBugs service, proxy's, Entry's and ServiceUI, that pass the
      test can be safely downloaded without DOS Attacks.
   2. SHA2 hashes can be used to identify safe codebases to download,
      the FindBugs service, only has to check each codebase once.
   3. The lookup service proxy doesn't need DownloadPermission, because
      the server subject is authenticated before downloading the proxy,
      unlike other proxy's.

What about SPKI certificates?

   1. SPKI was introduced to solve the issues with X.509
   2. Service subjects can give authentication certificates to their
      friends, or other companies, who can delegate these to their
      friends or employees.  The service knows the permissions the
      client requires, the client doesn't.
   3. The service doesn't need to know who the client is, it knows who
      delegated authority by the certificate chain.
   4. SPKI uses public keys for identity, so identity is globally
      unique.  Name spaces are defined locally, not globally, so you can
      give your friends any nick name you like.
   5. Anyone can generate their own SPKI public key, but they need
      someone else to give them authorisation, which they can store locally.
   6. Anonymity is possible.
   7. SPKI inverts dependency.
   8. SPKI isn't commercially attractive like X.509, because you don't
      need someone to sign your certificate.

So what could we do with this?

   1. If the proxy is safe to class load, without causing DOS, you don't
      need to trust the server subject, it can be anonymous.  The client
      can run as a subject with limited permission.  SSL Endpoints can
      be used for privacy between the two communicating parties.
   2. You don't need to trust the client subject either, it can remain
      anonymous, if no additional permission is required at the server end.
   3. You still need to trust the lookup service subject.  A local
      FindBugs service could be used to avoid the need to trust the
      lookup service subject.

Could this be used for E Commerce?

   1. Lets say there's an online service that you trust where you can
      make a deposit, lets say for example that Paypal provided a Jini
      Banking Service.
   2. E commerce services would also have an account with Paypal, so
      Paypal would have the identity (public keys) of both the E
      Commerce service and client.
   3. The client browses the E commerce service to purchase a product,
      or wants to use a resource the E commerce service provides, that
      could be advertising, cpu time on a compute farm, perhaps online
      games or movies.
   4. When the client is ready to make a purchase from the service, a
      transaction is used that involves the Paypal service, the payment
      is held until the client advises the product has been received.
   5. In this case the service subject grants an authorisation
      certificate to Paypal, it might last one day or for the period
      that the service is valid, Paypal then delegates this
      authorisation certificate to the client, and withdraws the money
      from the clients account.  The client uses the authorisation
      certificate to access the service.
   6. Trust is established in this case by a common third party.
   7. Other online banking institutions, could provide the same service.

What about preferred class loading and codebase annotation loss?

   1. We could automate preferred class loading to prevent codebase
      annotation loss, simply by using an @API annotation.  All classes
      reachable from a service API, would be loaded by the parent
      ClassLoader and all other classes would be loaded by the proxy
      class loader.  The proxy developer can still bug fix an existing
      Service API class by extending it.
   2. Using the @API annotation, I could quite easily add a flag to
      ClassDep, to not add API classes to proxy or service jars.  Then
      all classes in a proxy can be preferred, avoiding codebase
      annotation loss. 
   3. For anything outside of Java and Jini platforms, the proxy get's
      its own private namespace.
   4. See also http://www.rio-project.org/conventions.html

So I think we can make significant progress toward solving many 
difficulties.  I could use a little help though ;)

As for versioning, don't version Service API, don't change it, create a 
new service with a new name instead.  Suddenly versioning isn't an issue 
anymore, because proxy code is never published, it's a private concern.  
If your local River / Jini platform doesn't support something, update it.

Cheers,

Peter.