The JAAS Policy Class

Comment out this line to disable this feature. It applies both to standard and JAAS policy files. See Chapter 2. policy.allowSystemProperty=true This controls how Java 2 handles jar files signed by 1.1 utilities. When it encounters such a file and this property is false, the 1.1 IdentityScope will be used to find the signer of the file; if it is found in the scope and is trusted, the code will be granted all permissions. See Appendix C. policy.ignoreIdentityScope=false This specifies the default keystore type. For maximum safety, you should use jceks. See Chapter 10. keystore.type=jks This is the class that will be instantiated as the system IdentityScope used only in 1.1, though Java 2 programs that read 1.1−signed jar files will use it as well. See Appendix C. system.scope=sun.security.provider.IdentityDatabase This is the file that the default implementation of the IdentityScope class will use to load its database NOTE: The syntax of this entry is platform−specific since it is the name of a file and not a URL identity.database={java.home}identitydb.obj When a class loader does access checking, accessing a class in this list of packages will cause an exception to be thrown unless all protection domains have a RuntimePermission of accessClassInPackage.+package See Chapter 2 and Chapter 4. package.access=sun. If the class loader is performing package definition checks, then this is the list of packages in which code cannot define classes unless it belongs to a protection domain that has a runtime permission of defineClassInPackage.+package. However, no default class loader performs that check. See Chapter 2, Chapter 4, and Chapter 6. Note that no third−party class is allowed to define a class in the java package under any circumstance. package.definition= This property defines the class that will be used by the default SSL Server Socket Factory to create SSL server sockets. It is not set by default, in which case the class com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl will be used. Export restrictions prohibit setting this property in the global version of JSSE; if you set it in that version, it will be ignored. See Chapter 14. ssl.ServerSocketFactory.provider=\ com.sun.net.ssl.internal.ssl.SSLServerSocketFactoryImpl This property defines the class that will be used by the default SSL Socket Factory to create SSL sockets. It is not set by default, in which case the class com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl will be used. Export restrictions prohibit setting this property in the global version of JSSE; if you set it in that version, it will be ignored. See Chapter 14. ssl.SocketFactory.provider=\ com.sun.net.ssl.internal.ssl.SSLSocketFactoryImpl This property defines the algorithm that the default SSL key manager will use. It is not set by default, in which case Suns X509 keymanager will be used. See Chapter 14. sun.ssl.keymanager.type=SunX509 This property defines the algorithm that the default SSL trust manager will use. It is not set by default, in which case Suns X509 trust manager will be used. See Chapter 14. sun.ssl.trustmanager.type=SunX509 Appendix B. Security Resources Books are very useful for learning some things, and hopefully youve gotten some benefit from the one youre holding in your hand. However, for some types of information, the Internet remains the better choice. In this appendix, well list and discuss various network resources that relate to Java and security. One reason why this information is better found on the Internet is because it is subject to rapid change. The APIs weve discussed may remain fairly stable despite the big changes in many of them between 1.1 and Java 2, but the information to be found in these resources is more dynamic. B.1 Security Bugs Early in my computer science career, I handed in an exam that ended up receiving a lower grade than I had expected. [A] As part of the exam, I was asked to write an algorithm, prove that it was correct, and then provide an implementation of the algorithm. [A] Okay, that was not an unusual event for me... While my algorithm and its accompanying proof were completely correct, my implementation received a failing grade. This was a rather dispiriting result: I had come up with a solution and proved that the solution was correct. But the real answer −− the implementation −− was still flawed. Such is the potential problem with implementing a security model. A lot of design and analysis has gone into Javas default security model, and hopefully youll put your own effort into making your own applications secure. But no matter how sound the design of a security model, in the end it is the implementation that matters. In this section, well discuss some past bugs in Javas security implementation and list some common resources for finding out about and fixing present bugs. Few issues in the Java world receive more attention than security bugs; report of a new bug is guaranteed to produce a flurry of activity. As a result, readers of the trade press often have the idea that Java is riddled with security bugs or that it isnt secure to begin with. This is not the case. While some important bugs in Javas security implementation have been reported, the impact of these bugs has at least until now been minimal. Bugs that are reported against Javas security model fall into one of five categories: Reports that are not bugs but that arise from a lack of understanding of Javas security model. There are two types of very common bugs in this category: applets that perform annoying tasks and applets that seem to break out of the sandbox. The former category includes applets that take lots of CPU time or otherwise consume many resources. As we mentioned at the outset of this book, such attacks are annoying but are not security attacks. The latter category often involves bugs that hinge upon someone having installed a local class file or worse, a local native library; as we know by now, these local class files are treated as trusted classes. When one of these local classes is able to read or remove files on your disk, contact a machine on your local network, or engage in some other potentially malicious behavior, word goes out that Java is not secure or at best has bugs in its security model. The lesson to learn from these reports is this: no computer security model is a substitute for vigilant 1.