river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Sat, 09 Oct 2010 03:20:57 GMT
Sim IJskes - QCG wrote:
> On 10/08/2010 01:09 PM, Michal Kleczek wrote:
>> On Friday 08 of October 2010 13:02:17 Sim IJskes - QCG wrote:
>>> On 10/07/2010 09:57 PM, Michal Kleczek wrote:
>>>> So...
>>>> I've spent a day on some thinking and prototyping and hopefully I 
>>>> got an
>>>> idea. Here is an outline:
>>>
>>>> 1. We annotate classes with an object implementing Module interface:
>>> Is it safe to say that you are basically enhancing the codebase
>>> annotation pattern?
>> Basically - yes.
>> Although I am not sure I understand precisely your question... :)
>
> You understood correctly. :-) (i should have said, construct, well ok).
>
> I noticed the readAnnotation of MarshallInputStream reads an Object 
> and then casts it to a String. Are we sure that this is not a possible 
> vector for a deserialization attack? Personally i would have taken a 
> UTF-8 String (with limited length), but if you only unmarshall Objects 
> from TLS connections, that you check first, i guess its ok.
>
> So your solution is allowing for different credentials between the TLS 
> and the code source, and checking these credentials.
>
> Is this package pluggable onto river without modifications in river?

Are you sure that's a good idea?  Not modifying River I mean?

Michal's given this issue some thought.

It appears to solve the following problems:

   1. CodeSource identity is no longer based on it's originating URL
      location.
   2. Two services using the same proxy CodeSource don't share the same
      ClassLoader, one service can't gain the privileges of the other.

I'd had some thoughts about using Subject's in ClassLoader's with 
Identical CodeSource for distinct identity, however the Subject isn't 
known until after the classes are loaded.

I think we need to set up an issue on Jira and in skunk where we can 
collaborate and explore further development.

Something I'd like to further explore is a ClassLoader inheritance 
structure that places Service API and Jini Platform classes in a Parent 
ClassLoader and all application, service and proxy classes in child 
ClassLoaders, so they're forced to cooperate using the Service API, Jini 
and Java Platform classes.  This also ensures implementation classes 
aren't visible to proxy code, for good security.

Cheers,

Peter.


Mime
View raw message