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.
