摘自 winnerineast 的 Blog (1) The book I get is 2nd version, so it's still fresh even author released it in 2001. The book consists of 15 chapters each of which focuses on one of JAVA security topics. In the following days, I will share my study notes with you guys. First of all, I list the chapter list here (actually, you could find them around internet easily):Chapter 1, Java Application SecurityChapter 2, The Default SandboxChapter 3, Java Language SecurityChapter 4, The Security ManagerChapter 5, The Access ControllerChapter 6, Java Class LoaderChapter 7, Introduction to CryptographyChapter 8, Security ProvidorsChapter 9, Keys and CertificatesChapter 10, Key ManagementChapter 11, Message DigestsChapter 12, Digital SignaturesChapter 13, Cipher-Based EncryptionChapter 14, SSL and HTTPSChapter 15, Authentication and AuthorizationIf you review above titiles of chapters carefully and are familiar with JAVA Application anatomy, author presents his view along with JAVA topography nodes. Let's recall the whole JAVA anatomy as author did:-------------------------------------------------------------------------------------------- Remote Class Files Local Class Files--------------------------------------------------------------------------------------------- Signed Class Files--------------------------------------------------------------------------------------------- Bytecode Verifier----------------------------------------------------------------------------------------------Core API Class Files Class Loader-----------------------------------------------------------------------------------------------Security Package Core Java API----------------------------------------------------------------------------------------------- main of Security Manager + part of Access Controller----------------------------------------------------------------------------------------------- part of Security Manager + main of Access Controller------------------------------------------------------------------------------------------------ Key Database------------------------------------------------------------------------------------------------ Operating System-------------------------------------------------------------------------------------------------According to the above diagram, to add security logics up in every site of Java implementation is the essential thought of this book. Additionally, sandbox is the critical framework we need to follow. In real cases, the compromise between performance and effectiveness is hardly averted.So far we browse the overview of this book, I will go on my notes later. (2) Repeatly, the base of Java Security is sandbox model and the Security itself is a multifaceted feature of the Java platform. If you've enough patience to read the respective portion in JDK document, the class java.security document elaborate Java security mechanisms and API calling rules. To be frankly, I deem that to read Sun's document is better than to follow other alanogical papers. Remember, java.security is the place you need to visit when you are eager to find Java Security stuff.However, I still find one interesting tip in the book instead of Sun's Java document--java.security.debug, one property that can be set diverse values to trace different level's security events. Of course there is another counterpart named javax.net.debug. In the book, all samples could be traced by such debug setting. (3) Welcome to the framework of Java Security-- sandbox. It's true that the sandbox which is one of nature characters belonging to all interpreting programming languages. Not like C/C++ which nears with operating system, Java lives and works in itself world, a virtual world under Java macro instructions totally controlling. So security for Java doesn't matter. The chapter does not focus on the Java Virtual Machine Security Mechanism but security policys. From this point, the chapter is fit for those end users and administratives only. So from adminstrative point of view, the sandbox is composed of five elements: PermissionsCode sourcesProtection domainsPolicy filesKeystoresJava developers say it's platform technique. You're right. Before Java application runs in Java Virtual Machine including sandbox mechanism, administrative also program or configurate above elements to implement their security policy.Now let's come closer to five elements.Permission:No matter who wants to manage Java platform, he has to cope with Java API. Permission management follow such rule. You must take advantage of Java.security.Permission to achieve your goal. That means all Java class is under monitored because there is one respective set of permissions map with one Java class to define the activities that the class is allowed to perform. However, the compromise is that the core Java API always get permission to perform anything. Now the key question is how to set permission or how to work with permission? To be frankly, I also don't know how to do this. But the book will introduce the details.Here are core Java API permission.**********************************************************************File Permissions[Type]: java.io.FilePermission[Name]Because the file name is different in different operating system, the specific file name should be universal.${/}----------------/${user.home}----------------/home/userid${user.home}${/}file-------------------/home/userid/file[Actions]read,write, delete and executeSo when we define one file permission, the most like statement ispermission java.io.FilePermission “<<ALL FILES>>”, “read,write,delete,execute”;permission java.io.FilePermission “${user.home}$/mypassword”,“read”;I need to highlight one thing here that the file permission defined above can only take effect in Java Virtual Machine. It's eay to be destroyed by operatinh system configuration. For instance, one file is allowed to be deleted by user but has been set to read only under UNIX. If user is noy super user, he still can not delete the file as he wants.**********************************************************************Socket Permissions[Type]java.net.SocketPermission[Name]hostname:port ,such as java.sun.com:1020.Of couse a wildcard can be used like:127.1.10.*:8080.Another flexible usage is '-'. You can set :1024- means 1024 and all ports geater than 1024-1024 means 1024 and all ports less than 10241-204 means from 1 to 1024 but exclude two ends[Actions]accept, listen, connect and resolve.permission java.net.SocketPermission “127.*:1-”,”accept, listen, connect, resolve”;**********************************************************************Property Permission[Type]java.util.PropertyPermission[Name]Any java class or package name just like what you define in the front of source code.[Actions]read and writepermission java.util.PropertyPermission “java.*“, “read“;**********************************************************************Runtime Permissions[Type]java.lang.RuntimePermission[Name]There are a lot of various definitions. Please refer to sun java api document. Because many of them relate to very low level Java runtime configuration. This portion is the essential part of Java sandbox processing.permission java.lang.RuntimePermission “queuePrintJob“;**********************************************************************AWT Permissions[Type]java.awt.AWTPermission[Name]accessClipboardaccessEventQueueaccessRobotlistenToAllAWTEventsreadDisplayPixelsshowWindowWithoutWarningBanner[Actions]NASo you can easy write the permission script like permission java.awt.AWTPermission “createRobot”;**********************************************************************Net Permission[Type]java.net.NetPermission[Name]I am not sure that what it exactly means. So I have to write the original text here for your information.”There are three names associated with this class. specifyStreamHandler allows new stream handlers to be installed into the URL class. HTTP authentication(which is not exactly implemented by default Java implementations) requires two permissions: setDefaultAuthenticator to install the authentication class and requestPasswordAuthentication to complete the authentication.”[Action]NApermission java.net.NetPermission “specifyStreamHandler”;**********************************************************************Security Permission[Type]java.security.SecurityPermission[Name]Various. addIdentityCertificateclearProviderProperties...No comment on this portion. Maybe when I finish the first five chapters, I could understand what the author states here.**********************************************************************Serializable Permission[Type]java.io.SerializablePermission[Name]enableSubstitution and enableSubclassImplementation.No comment too.**********************************************************************Reflection Permission[Type]java.lang.reflect.ReflectPermission[Name]suppressAccessChecks. If granted, this permission allows reflection to examine the private variables of arbitrary classes.No comment as well.**********************************************************************All Permission[Type]java.security.AllPermissionNo need to introduction. This is that famous but dummy one. (4) If you also read the book, you will observe I did not follow the book's chapter fully. Because I think some logics need to be discussed together such as permission and policy files. Yes, policy files are the place storing various security permission we have discussed before. Normally, the files are in $JREHOME/lib/security/. You could configurate any type of policy files for your Java Virtual Machine. However, the default one is named with java.policy that is used by all Java instance.In addition, author said there is a user-specific policy file called .java.policy. But I can not find it in my JDK directory. Maybe my J2SE 1.4.2 has been changed. But I could list my java policy file here. // Standard extensions get all permissions by default grant codeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission;}; // default permissions granted to all domains grant { // Allows any thread to stop itself using the java.lang.Thread.stop() // method that takes no argument. // Note that this permission is granted by default only to remain // backwards compatible. // It is strongly recommended that you either remove this permission // from this policy file or further restrict it to code sources // that you specify, because Thread.stop() is potentially unsafe. // See "http://java.sun.com/notes" for more information. permission java.lang.RuntimePermission "stopThread"; // allows anyone to listen on un-privileged ports permission java.net.SocketPermission "localhost:1024-", "listen"; // "standard" properies that can be read by anyone permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read";}; Now, all the Java Sandbox work according to this policy file. I take note of one change that my JRE's java policy file has not keystore configuration. Is it anything wrong on my install or configuration? I will investigate this one later.If we try to manage Java Virtual Machine by policy file, we need to configurate it via permission rules. Yet this is not enough to guarantee security configuration.There are still another two sects--keystore and code source. Keystores is used to sign Java code and only after user get pulibc key, he can run the signed code. As for code sources, it's a combination of codebases and signers. That means that you must tell others which code is signed by what type of keystores.Keystores, code sources and policy file are the foundation of Java security sandbox configuration. And how do they work? Some tools. If you are an old Sun user, you even can guess the tool's name--policytool.I hate to write more boring operating steps here. I think you can find break-down in every Sun Java document.Now we could put them together and examinate how it works. I will share my experience with you in next notes. (5) And now, we kick off sandbox discussion. Firstly, Java application that is invoked via Java command line, the sandbox is initially disabled. Why? Author did not immediately give us the answer. I deem that this is due to Java Application is running in local machine and can access any local resources naturally. The local system security is charge of operating system.If you want to enable security. Then you must call:java -Djava.security.manageer ......When the manager is enable, you could assign the policy file to replace current default file like:java -Djava.security.policy=<URL>On the other hand, Appletviewer has security manager which can not be disabled. Why? This is easy to understand that applet is limited application that can only run in certain sandbox(this is sepcial limitation for network application deployment). In this point of view, there is another type Java component --Plug-in -- which has analogical mechanism but more complete than applet. It can also support interactive security request with user. You sometimes see one popup window to warn you there is one java signed file is running and you could choose enable or disable it.Only administrative will have interest on Java security policy file configuration. Otherwise, it's very boring work. I will skip the details that you could read from any Sun JDK document.Till now, I can image that when you install one J2SE or J2EE environment in your machine. Java is ready on security with policy file and potential ketstores to sign your java class written by you. (6) The five segments of notes take me three days to recall the basic knowledge of Java Security Mechanism--sandbox. But I like the language itself. Because I could control everything. Once your administrator set up environment for you, when you hope to get more authorization and right, you have to write e-mail, fill application form and ask your boss to approve it. What's troublesome nuts!So I will start new topic--Java Languages Security. This is more interesting for me and more comfortable to express what I try to explain. But I don't discuss those exceptions such as native code that always trigger the problem as it's more like C/C++ code instead of Java code. As we all know, C/C++'s secuirty reply on yourself majorly.Please remember these:public, protect, private, final . They are much better than C++. Because programmer haven't pointer to help them to snoop on hidden components in the class. Another good news is that Java forbid to arbitrarily cast class type unless there is some relationship between them such as derivative. Of course , you still can not stop memory snooper. What a pity!The second bonus or maybe danger is object serialization. The file stored in hard disk. A lot of crazy guys could read it after trying with many times. How can we cope with it? One is to avoid from using it. The other is to encode them and override the writer and loader function.The third tool is Javac , compiler tool. It can help to check security but weak functionality.The forth trouble is from Java language itself. This problem is like Hook technique which have been used in network card capture application or API replacement. From the Java view, this is more easier than C++. Because there is one virtual machine used for application. Sun adds one bytecode verifier into virtual machine to detect corrupted code or illegal code. But Java uses special skill to do such detection--to verify bytecode only when the bytecode is performing. But it's not the runtime check. The real runtime check does not check class attribute but check array bounds and object casting.As author said that the notion of security in Java is pervasive, its implementation is equally pervasive. (7) In the previous 6 notes, I outline Java Securty, this book's first three chapters. The essential meaning of them is to introduce the framework of Java Security Mechanism--sandbox and basic knowledge pertained with Java language.Now, we enter the two critical portions--security manager and access controller. Because I suppose you are a good java programmer and at least are familar with Java language and basic classes, the detail information will be bypass and please refer to Sun Java documents. Here I only highlight the skeleton. 1. Security manager and Access controller are halfs of whole Java security interface. From calling view, core Java APIs call security manage interface and access controller takes charge of implementation of access control..2. From evolution view, Security manager is the carry-over of pre-Java 2 program and works for being compatible with old version.3. Both Security manager and Access controller are the parts of Java Virtual Machine.4. There are four basic functionalities in security manager class methods. The method relating to file access, the method relating to network access, the method relating to Java Virutal Machine security and the method protecting program thread and the methods protecting system resources such as printer as well. 5. As for Access controller, it implements most of security manager's logics.(I will write context in Notes 8 for Access Controller.)

评论