Sponsored Link •
Bob Scheifler talks with Bill Venners the dynamic granting of permissions to Jini proxies.
Many potential applications of Jini require network security. Although various third parties have made proprietary security extensions to Jini, until now the only security available to users of the standard Jini release is the security infrastructure of the Java platform. The Jini Community's Davis project is about to change that. Bob Scheifler is leading the development of the next release of Jini, in which security is the central concern, as part of the Davis project.
On Friday, April 12, 2002 Bill Venners visited the Sun Microsystems campus in
Burlington, Massachusettes and interviewed
Bob Scheifler, Sun Distinguished Engineer and architect in the Jini Group.
In Part I of this interview, Scheifler discusses the need for security in Jini and the special security considerations
of dynamically downloaded code.
In Part II, Scheifler describes the mechanisms used to determine whether a proxy should be trusted.
In Part III, Scheifler covers the mechanisms used to achieve object integrity.
In Part IV, Scheifler discusses security constraints and the
In this fifth installment of the interview, Scheifler describes the dynamic granting of permissions to proxies.
Bill Venners: How do clients dynamically grant permissions to proxies at runtime?
Bob Scheifler: You have to decide if you trust the proxy, then you have to decide what you will allow the proxy to do. That is the process of authorization, where you grant permissions in the standard Java model. You authorize by granting permissions. Somehow we have to grant the proxy permissions dynamically.
We have to grant permissions dynamically for a couple of reasons. One is that in the standard Java security model you grant permissions to a code base or to URLs. But in the Jini world, you don't want to have to know where the code came from. That should be an implementation detail.
Say you are a service, and I have a proxy from you. I don't want to have to know what URL you serve code from. One reason I can't do a static grant is I generally don't know where your code comes from. I don't want to grant permissions to code from anywhere because that would be granting to untrusted code. And even if I know where your code is now, you might change your mind later about whether that is really the trusted code or not. What I really want to do is wait until after I have decided I trust the proxy before I grant it any permission. If I grant it permissions before I decide I trust it, then it may have already abused those permissions behind my back and already done damage.
From the time I unmarshal that object, if I have already granted it permissions, it can already exercise those permissions while it is being unmarshalled. So I want to make sure that I don't grant it any permissions until after I decide I trust it. That is where the dynamic granting comes into play. I don't want to characterize these permissions in a static security policy. At runtime I get a proxy from somewhere. I decide I trust it. And then I want to grant it permissions.