I have experienced on a number of different machines that a signed applet that the client trusts (via clicking on yes to the prompt asking to trust the applet), is able to access the local resources with NO policy file on the client machine. I'm using JRE 1.4.1_02 Is this the expected behavior? I sure hope it is because how in the world can you install applications to many clients and update their policy file? you can't via the web! BUT why am I reading that you have to have a policy file even if you sign an applet. I want to get rid of using Netscape security model but I can not update many client machine policy files... Please help!!! thanks. Is signing an applet all you have to do to access local machines, I sure hope so! Thanks in advance.
You've got your policy mods confused. The applet carries its own policy file indicating what actions are permitted and what actions are denied. When you sign the applet, it signs the entire applet, including the policy file. Because it's part of the signed applet, attempting to replace a class in the applet jar will cause the signature to fail - as will attempting to modify the jar's policy file. I take it for granted that a higher-level policy could be applied to the browser's JVM that could veto (but not add) policies, but I've not yet come across anything that explained it succintly. Then again, I haven't been looking too hard. I have been nudging a certain publisher about geting more out on that topic though.
An IDE is no substitute for an Intelligent Developer.
hi Tim, i didn't understand, The applet carries its own policy file indicating what actions are permitted and what actions are denied. can you please explain with example? do you mean that we can include the policy file in the applet jar? regards maulin
Not "can", but "must". However I've not been required to worry about applet security for two years now (or anything else that involves getting paid for working with computers and/or software ). And my understanding is muddy since the last time I did worry about such things, browsers and Java's security system were much different. By making the applet security policy file part of the signed jar, it ensures that in addition to being barred from substituting evil replacements for classes, the user also can't find evil things to do with the original applet classes, then replace the policy file with a less restrictive one to exploit those uses. For anything more specific I'd have to RTFM.
Joined: Apr 27, 2003
I've done some more research specifically a very good article at http://developer.java.sun.com/developer/technicalArticles/Security/applets/index.html. I'll try to highlight the more interesting comments that I found. But first I don't think (although Tim seems pretty sure that you need it), I don't think that you have to place a policy file in your singed jar file. At least for the JRE 1.3 there appears to be a new class loader, sun.plugin.security.PluginClassLoader that allows a signed jar file (once trusted by the client) to have access to local resources. Code signed using the private key of the signer can be run on client machines once the public key corresponding to the signer is deemed as trusted on the respective machine. Applet security in browsers strives to prevent untrusted applets from performing potentially dangerous operations, while simultaneously allowing optimal access to trusted applets. There is no simply way to deploy and use customized policy files, a policy will have to be set by files based on the JRE installation. Customized class loaders or security managers cannot be installed easily. Policy files are difficult or at least not very straightforward for normal users, which could be thousands of machines where an applet is deployed. The java plug-in (I believe its 1.3 and later) provides a workaround although its recommended to use policy files wherever practical and applicable. (This implies to me that using the plug-in, all that is required is to sign the jar file to have access to local resources). RSA-signed applets can be deployed using the Java plug-in. (which can run in an identical way for Netscape and IE). In order for a plug-in enhanced browser to trust an applet and grant it all privileges or a set of fine-grained permissions (as specified in a J2EE policy file), the user has to preconfigure his or her cache of trusted signer certificates (the .keystore file in JRE 1.3) to add the applet's signer to it. However, this solution does not scale well if the applet needs to be deployed on thousands of client machines, and may not always be feasible because users may not know in advance who signed the applet that they are trying to run. A NEW CLASS LOADER, sun.plugin.security.PluginClassLoader in the Java Plug-in 1.3, OVERCOMES THE LIMITATIONS MENTIONED ABOVE. I hope this helps, I've been looking for this solution for quite some time, trying to understand why singed applets work with no policy files for version 1.4... Talk to you later, Jay. [ June 17, 2003: Message edited by: Jay Schrock ]