[ Pobierz całość w formacie PDF ]
.Of course, thisassumes that the browser can determine which applets it ought to trust.We'll see how thisproblem is solved shortly.The integrity of a security manager is based on the protection afforded by the lower levels of theJava security model.Without the guarantees provided by the verifier and the class loader, high-level assertions about the safety of system resources are meaningless.The safety provided bythe Java byte-code verifier means that the interpreter can't be corrupted or subverted, and thatJava code has to use components as they are intended.This, in turn, means that a class loadercan guarantee that an application is using the core Java system classes and that these classesare the only means of accessing basic system resources.With these restrictions in place, it'spossible to centralize control over those resources with a security manager.1.6 Application and User-Level SecurityThere's a fine line between having enough power to do something useful and having all thepower to do anything you want.Java provides the foundation for a secure environment in whichuntrusted code can be quarantined, managed, and safely executed.However, unless you arecontent with keeping that code in a little black box and running it just for its own benefit, you willhave to grant it access to at least some system resources so that it can be useful.Every kind ofaccess carries with it certain risks and benefits.The advantages of granting an untrusted appletaccess to your windowing system, for example, are that it can display information and let youinteract in a useful way.The associated risks are that the applet may instead display somethingworthless, annoying, or offensive.Since most people can accept that level of risk, graphicalapplets and the World Wide Web in general are possible.At one extreme, the simple act of running an application gives it a resource, computation time,that it may put to good use or burn frivolously.It's difficult to prevent an untrusted application fromwasting your time, or even attempting a "denial of service" attack.At the other extreme, apowerful, trusted application may justifiably deserve access to all sorts of system resources (e.g.,the filesystem, process creation, network interfaces); a malicious application could wreak havocwith these resources.The message here is that important and sometimes complex securityissues have to be addressed.In some situations, it may be acceptable to simply ask the user to "okay" requests.Sun's HotJavaweb browser can pop up a dialog box and ask the user's permission for an applet to access anotherwise restricted file.However, we can put only so much burden on our users.An experiencedperson will quickly grow tired of answering questions; an inexperienced user may not be able toanswer the questions correctly.Is it okay for me to grant an applet access to something if I don'tunderstand what that is?Making decisions about what is dangerous and what is not can be difficult.Even ostensiblyharmless access, like displaying a window, can become a threat when paired with the ability foran untrusted application to communicate from your host.The Java Security Manager provides anoption to flag windows created by an untrusted application with a special, recognizable border toprevent it from impersonating another application and perhaps tricking you into revealing yourpassword or your secret recipe collection.There is also a grey area, in which an application cando devious things that aren't quite destructive.An applet that can mail a bug report can also mail-bomb your boss.The Java language provides the tools to implement whatever security policiesyou want.However, what these policies will be ultimately depends on who you are, what you aredoing, and where you are doing it.1.6.1 Signing ClassesWeb browsers such as HotJava start by defining a few rules and some coarse levels of securitythat restrict where applets may come from and what system resources they may access.Theserules are sufficient to keep the waving Duke applet from clutching your password file, but theyaren't sufficient for applications you'd like to trust with sensitive information.To fully exploit thepower of Java, we need to have some nontechnical basis on which to make reasonable decisionsabout what a program can be allowed to do.This nontechnical basis is trust; basically, you trustcertain entities not to do anything that's harmful to you.For a home user, this may mean that youtrust the "Bank of Boofa" to distribute applets that let you transfer funds between your accounts,or you may trust L.L.Bean to distribute an applet that debits your Visa account.For a company,that may mean that you trust applets originating behind your firewall, or perhaps applets from afew high-priority customers, to modify internal databases.In all of these cases, you don't need toknow in detail what the program is going to do and give it permission for each operation.You onlyneed to know that you trust your local bank.This doesn't mean that there isn't a technical aspect to the problem of trust.Trusting your localbank when you walk up to the ATM means one thing; trusting some web page that claims tocome from your local bank means something else entirely.It would be very difficult toimpersonate the ATM two blocks down the street (though it has been known to happen), but,depending on your position on the Net, it's not all that difficult to impersonate a web site, or tointercept data coming from a legitimate web site and substitute your own.That's where cryptography comes in [ Pobierz całość w formacie PDF ]