[ Pobierz całość w formacie PDF ]
.class file and carefully looked over by the verifier.Once they are declared safe, the interpreter can execute them for you (or a code generator can generate native binary code for them using either the “just-in-time” compiler or java2c, and then run that native code directly).At each stage, more and more security is added.The final level of that security is the Java class library itself, which has several carefully designed classes and APIs that add the final touches to the security of the system.The Security ManagerSecurityManager is an abstract class that was recently added to the Java system to collect, in one place, all the security policy decisions that the system has to make as bytecodes run.You learned before that you can create your own class loader.In fact, you may not have to, because you can subclass SecurityManager to perform most of the same customizations.An instance of some subclass of SecurityManager is always installed as the current security manager.It has complete control over which of a well-defined set of “dangerous” methods are allowed to be called by any given class.It takes the realms from the last section into account, the source (origin) of the class, and the type of the class (stand-alone, or loaded by an applet).Each of these can be separately configured to have the effect you (the programmer) like on your Java system.For nonprogrammers, the system provides several levels of default security policies from which you can choose.What is this “well-defined set” of methods that are protected?File I/O is a part of the set, for obvious reasons.Applets, by default, can open, read, or write files only with the express permission of the user—and even then, only in certain restricted directories.(Of course, users can always be stupid about this, but that's what system administrators are for!)Also in this protected set are the methods that create and use network connections, both incoming and outgoing.The final members of the set are those methods that allow one thread to access, control, and manipulate other threads.(Of course, additional methods can be protected as well, by creating a new subclass of SecurityManager that handles them.)For both file and network access, the user of a Java-capable browser can choose between three realms (and one subrealm) of protection:lunrestricted (allows applets to do anything)llfirewall (allows applets within the firewall to do anything)llsource (allows applets to do things only with their origin Internet host, or with other applets from there)lllocal (disallows all file and network access)lFor file access, the source subrealm is not meaningful, so it really has only three realms of protection.(As a programmer, of course, you have full access to the security manager and can set up your own peculiar criteria for granting and revoking privileges to your heart's content.)For network access, you can imagine wanting many more realms.For example, you might specify different groups of trusted domains (companies), each of which is allowed added privileges when applets from that group are loaded.Some groups can be more trusted than others, and you might even allow groups to grow automatically by allowing existing members to recommend new members for admission.(The Java seal of approval?)In any case, the possibilities are endless, as long as there is a secure way of recognizing the original creator of an applet.You might think this problem has already been solved, because classes are tagged with their origin.In fact, the Java run-time goes far out of its way to be sure that that origin information is never lost—any executing method can be dynamically restricted by this information anywhere in the call chain.So why isn't this enough?Because what you'd really like to be able to do is permanently “tag” an applet with its original creator (its true origin), and no matter where it has traveled, a browser could verify the integrity and authenticate the creator of that applet.Just because you don't know the company or individual that operates a particular server machine doesn't mean that you want to mistrust every applet stored on that machine.It's just that, currently, to be really safe, you should mistrust those applets.If somehow those applets were irrevocably tagged with a digital signature by their creator, and that signature could also guarantee that the applet had not been tampered with, you'd be golden.NOTELuckily, Sun is planning to do exactly that for Java, as soon as export restrictions can be resolved.Here's a helpful hint of where the team would like to go, from the security documentation: “.a mechanism exists whereby public keys and cryptographic message digests can be securely attached to code fragments that not only identify who originated the code, but guarantee its integrity as well.This latter mechanism will be implemented in future releases.”Look for these sorts of features in every release of Java; they will be a key part of the future of the Internet!One final note about security.Despite the best efforts of the Java team, there is always a trade-off between useful functionality and absolute security.For example, Java applets can create windows, an extremely useful capability, but a “nasty” applet could use this to spoof the user into typing private password information, by showing a familiar program (or operating system) window and then asking an expected, legitimate-looking question in it.(The 1.0 release adds a special banner to applet-created windows to solve this problem.)Flexibility and security can't both be maximized.Thus far on the Net, people have chosen maximum flexibility, and have lived with the minimal security the Net now provides.Let's hope that Java can help tip the scales a bit, enabling much better security, while sacrificing only a minimal amount of the flexibility that has drawn so many to the Net.SummaryIn this chapter we discussed the grand vision that some of us have for Java, and about the exciting future it promises
[ Pobierz całość w formacie PDF ]
