Nice! 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 <[email protected]> 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 >>>
