> you have time to decide whether or not you take the risk. You're right, you do. But I'm not convinced that this makes much of a difference.
In your browser, if you click on a nasty link and suddenly start seeing horrible pictures appear on your screen, sure you can go back, cancel or stop your browser. Realistically, you've only got while the page is downloading in which to change your mind. (Even less now that some browsers will start rendering/running that page before the download is complete.) But chances are, that nasty Java Script at the top of the page has already done something malicious before you had a chance to stop it. In your service browser, you can click on the download button of some Jini service to download the proxy for it, and you've only got the amount of time it takes to do the download to change your mind (assuming there is no "Proxy downloaded, are you sure you want to use?" type dialog). There is a much greater time lag between downloading a malicious JAR file and running it. I absolutely agree with you; but once you've downloaded what's the probability that you're going to inspect the code before deciding whether or not to run it? > trusting the source ... does not imply anything about the quality of the code you're about to execute I disagree, and I use the example of Log4J (again) to demonstrate this. I trust Apache, tons of other people do to. I trust that the code I download is both well intentioned and correctly written. I can honestly say that I have never verified either assumption, nor restricted my Log4J usage environment to prevent it from doing anything "bad". I can completely believe that trust and security is very difficult, that you're far better at it than me and have forgotten more about it than I'll ever know. What I'm suggesting though, is to shift the goal posts so we only have to solve a (hopefully) more simple problem. If you trust my (public) ServiceRegistrar and you trust the download channel, can you be convinced to trust whatever proxy you request from me? If we can make that answer "yes", then all the proxy permission difficulty suddenly goes away. On Fri, Oct 1, 2010 at 1:05 PM, Zoltan Juhasz <[email protected]> wrote: > Tom and all, > > > When was the last time you analysed the contents of your > > newly downloaded log4j.jar, just to make sure it didn't > > contain anything nasty? In that example, you trusted the > > download site (apache.org), and you trusted the download > > mechanism (HTTP - now that was risky!), and then you trusted > > the stuff you downloaded. > > I think this is a key observation. The Jini mechanism for trust is based on > trusting the source and the download channel but that does not imply > anything about the quality of the code you're about to execute. When you > download anything manually (in your browser), you have time to decide > whether or not you take the risk. Jini however is about programmatic > clients > doing this automatically without human intervention. The speed of execution > is at a different scale. One would need semantic correctness checks which > is > impossible to do right now. We had bumped into this problem when we used > Jini for distributed/parallel computation and the only solution we could > come up was to have accountability and a mechanism for non-repudiation, ie > you code can do stupid things but I'll catch you and make you pay for it. > > I don't know whether there is a universal solution to this, it is a very > complicated problem. > > Zoltan > > >
