[ Pobierz całość w formacie PDF ]
.Fortunately, Java is a big part of the answer.NOTEFor more information about security issues with Java, please see Chapter 40, “Java Security.”Why You Might Not Have ToWhat gives me any confidence that the Java language and environment will be safe, that it will solve the technically daunting and extremely thorny problems inherent in any good form of security, especially for networks?One simple reason is the history of the people, and the company, that created Java.Many of them are the very smart programmers referred to throughout the book, who helped pioneer many of the ideas that make Java great and who have worked hard over the decades to make techniques such as garbage collection a mainstream reality.They are technically capable of tackling and solving the hard problems that need to be solved.In particular, from discussions with Chuck McManis, one of Java's security gurus, I have confidence that he has thought through these hard problems deeply, and that he knows what needs to be done.Sun Microsystems, the company, has been pushing networks as the central theme of all its software for more than a decade.Sun has the engineers and the commitment needed to solve these hard problems, because these same problems are at the very center of both its future business and its vision of the future, in which networking is the center of everything—and global networks are nearly useless without good security.Just this year, Sun has advanced the state of the art in easy-to-use Internet security with its new SunScreen products, and it has assigned Whitfield Diffie to oversee them, who is the man who discovered the underlying ideas on which essentially all interesting forms of modern encryption are based.Enough on “deep background.” What does the Java environment provide right now that helps me feel secure?Java's Security ModelJava protects you against potential “nasty” Java code via a series of interlocking defenses that, together, form an imposing barrier to any and all such attacks.CAUTIONOf course, no one can protect you from your own ignorance or carelessness.If you're the kind of person who blindly downloads binary executables from your Internet browser and runs them, you need read no further! You are already in more danger than Java will ever pose.As a user of this powerful new medium, the Internet, you should educate yourself to the possible threats this new and exciting world entails.In particular, downloading “auto-running macros” or reading e-mail with “executable attachments” is just as much a threat as downloading binaries from the Net and running them.Java does not introduce any new dangers here, but by being the first mainstream use of executable and mobile code on the Net, it is responsible for making people suddenly aware of the dangers that have always been there.Java is already, as you will soon see, much less dangerous than any of these common activities on the Net, and can be made safer still over time.Most of these other (dangerous) activities can never be made safe.So please, do not do them!A good rule of thumb on the Net is this: Don't download anything that you plan to execute (or that will be automatically executed for you) except from someone (or some company) you know well and with whom you've had positive, personal experience.If you don't care about losing all the data on your hard drive, or about your privacy, you can do anything you like, but for most of us, this rule should be law.Fortunately, Java allows you to relax that law.You can run Java applets from anyone, anywhere, in relative safety.Java's powerful security mechanisms act at four different levels of the system architecture.First, the Java language itself was designed to be safe, and the Java compiler ensures that source code doesn't violate these safety rules.Second, all bytecodes executed by the run-time are screened to be sure that they also obey these rules.(This layer guards against having an altered compiler produce code that violates the safety rules.) Third, the class loader ensures that classes don't violate name space or access restrictions when they are loaded into the system.Finally, API-specific security prevents applets from doing destructive things.This final layer depends on the security and integrity guarantees from the other three layers.Let's now examine each of these layers in turn.The Language and the CompilerThe Java language and its compiler are the first line of defense.Java was designed to be a safe language.Most other C-like languages have facilities to control access to “objects,” but also have ways to “forge” access to objects (or to parts of objects), usually by (mis-)using pointers.This introduces two fatal security flaws to any system built on these languages.One is that no object can protect itself from outside modification, duplication, or “spoofing” (others pretending to be that object).Another is that a language with powerful pointers is more likely to have serious bugs that compromise security.These pointer bugs, where a “runaway pointer” starts modifying some other object's memory, were responsible for most of the public (and not-so-public) security problems on the Internet this past decade.Java eliminates these threats in one stroke by eliminating pointers from the language altogether.There are still pointers of a kind—object references—but these are carefully controlled to be safe: they are unforgeable, and all casts are checked for legality before being allowed.In addition, powerful new array facilities in Java not only help to offset the loss of pointers, but add additional safety by strictly enforcing array bounds, catching more bugs for the programmer (bugs that, in other languages, might lead to unexpected and, thus, bad-guy-exploitable problems).The language definition, and the compilers that enforce it, create a powerful barrier to any “nasty” Java programmer.Because an overwhelming majority of the “Net-savvy” software on the Internet may soon be Java, its safe language definition and compilers help to guarantee that most of this software has a solid, secure base.With fewer bugs, Net software will be more predictable—a property that thwarts attacks.Verifying the BytecodesWhat if that “nasty” programmer gets a little more determined, and rewrites the Java compiler to suit his nefarious purposes? The Java run-time, getting the lion's share of its bytecodes from the Net, can never tell whether those bytecodes were generated by a “trustworthy” compiler.Therefore, it must verify that they meet all the safety requirements.Before running any bytecodes, the run-time subjects them to a rigorous series of tests that vary in complexity from simple format checks all the way to running a theorem prover, to make certain that they are playing by the rules [ Pobierz całość w formacie PDF ]

Archiwum