river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Towards Internet Jini Services (trust)
Date Tue, 05 Oct 2010 14:07:18 GMT

Sent from my iPhone

Michael McGrady
Principal investigator AF081_028 SBIR
Chief Architect
Topia Technology, Inc
Work 1.253.572.9712
Cel 1.253.720.3365

On Oct 5, 2010, at 6:36 AM, Michal Kleczek <michal.kleczek@xpro.biz> wrote:

> Looks like the real underlying issue in understanding is the definition of the 
> Jini Platform.
> How I see it is: the platform is the _minimal_ set of software that I need to 
> manually install on my computer to safely exchange objects (code + data) with 
> other computers and run the code that constitutes those objects.
> Everything else should be implemented as a service (an object) that is run on 
> top of the platform - and should not be considered a part of the platform.
> I would even say it should be discussed if discovery protocols and 
> ServiceRegistrar definition are part of the platform.
> So what do we have now?
> JVM - necessary to have dynamic code downloading and permissions
> PreferredClassProvider and PreferredClassLoader - necessary to deal with 
> codebase issues
> IntegrityVerifier interface, httpmd url handler and HttpmdIntegrityVerifier - 
> necessary to make sure we download the right code to unmarshal an object (BTW 
> - are there any fundamental security issues with having other 
> UrlStreamHandlers and IntegrityVerifiers provided as services - similarly to 
> how OSGI does that?)
> TrustVerifier, ProxyTrust, RemoteMethodControl, Constraint, ProxyPreparer 
> interfaces and their basic implementations - necessary to verify unmarshalled 
> objects
> various JERI endpoint implementations - necessary to be able to implement 
> ProxyTrust (BTW should unsecure endpoints like TcpEndpoint _really_ be part of 
> the platform?)
> As I see it - if we close the gap and solve the issue of possible DoS during 
> deserialization we have a complete platform to build everything else as 
> services on top of it.
> Even complicated trust decisions can be made by delegating to trusted 
> services.
> We can quite easily build "sandbox" services (for example on top of Phoenix) 
> so that the client can choose not to download any code into it's own address 
> space.
> What am I missing?
> Michal
> On Tuesday 05 of October 2010 13:07:35 Peter Firmstone wrote:
>> Yes I think Sim is talking about making trust decisions and Michal and I
>> are talking about the handshake, we need both, I don't think we're
>> having an issue of agreement, just understanding.
>> I'd like to see some kind of feedback service, where you give a good
>> rating when you get a good service and a bad one when you don't.  I'd
>> also like to see a security advisory service, for handling discovered
>> vulnerabilities.  These things might be useful in making trust decisions.
>> I'd also like some trust levels defined, with a wider range of
>> permissions as trust increases.  But I'd only like to grant the
>> intersection of the trust level Set of Permissions and the Set requested.
>> I'd like to see the level of trust others are granting to a service via
>> feedback services, if a service misbehaves and it's caught out, the
>> level of trust will diminish.
>> Then we can go with the crowd, safety in numbers, like a school of fish,
>> just don't get caught in a bait ball.
>> Cheers,
>> Peter.
>> Michal Kleczek wrote:
>>> Of course - I am not talking about the problem of deciding whether I
>>> should trust a particular service - this is a completely different
>>> subject and I am not really sure if we should even try to solve it since
>>> I don't think it is possible to do without human intervention. In the
>>> end - choosing to trust and use gmail versus yahoo is not something that
>>> can be done automatically.
>>> But checking whether an object (code + data) comes from the service I
>>> trust is something that can be done and is a prerequisite to the above
>>> anyway.
>>> Michal

View raw message