Keystores The Default Sandbox
2.4 Code Sources
Code sources are a combination of codebases and signers. The signer field must match the alias listed in the keystore, as weve just described. Codebases can be any valid URL. Because they are URLs, codebases always use forward slashes, even if the code is being read from the filesystem: file:C:filesjdk1.3 is the correct specification for the directory C:\files\jdk1.3\ although remember that if the drive is the default drive, you can leave it out and specify the URL as file:filesjdk1.3 . Codebases can use property substitution much like we showed when discussing file properties. Hence, the codebase for the Java extension directory can be universally specified as file:{java.home}libext. This trick applies somewhat to the classpath: if you want a particular set of permissions to apply to all classes on the classpath then you can use the codebase file:{java.class.path}. However, this works only when there is a single directory or JAR file in the classpath since only those cases result in a correct URL. The ending of the codebase URL is very important. There are four cases: The URL specifies a jar file http:www.sun.comsdosdoapp.jar. Only the classes in the jar file belong to the codebase. • The URL ends with a slash http:www.sun.comsdo. Only class files in the given directory belong to the codebase. Jar files in the given directory do not belong to the codebase. • The URL ends with an asterisk http:www.sun.comsdo. Both jar files and class files in the given directory belong to the codebase. However, jar and class files in subdirectories of the URL do not belong to the codebase. • The URL ends with a hyphen http:www.sun.comsdo−. All jar and class files in the given directory and its subdirectories belong to the codebase. • Note this directory syntax is not affected by package names. If you want to give permissions to the class com.sdo.PayrollApp , you list the directory in which the com subdirectory appears e.g., http:www.sdo.net, not http:www.sdo.netcomsdo.2.5 Policy Files
In order to administer the Java sandbox, you list the various permissions weve discussed in a Java policy file. Java virtual machines can use any number of policy files, but there are two that are used by default. There is a global policy file named JREHOMElibsecurityjava.policy that is used by all instances of a virtual machine on a host. We consider this to be a global policy file because it allows an environment where the JRE is mounted from a common server by several machines; each of these machines will share the definitions in this file. In addition, there is a user−specific policy file called .java.policy that may exist in each users home directory HOME on UNIX systems, C:\WINDOWS on single−user Windows 98 systems, and so on. The set of permissions given to a program is the union of permissions contained in the global and user−specific policy files. Policy files are simple text files. You can administer them with policytool , or you can edit them by hand. Hand editing is discouraged in 1.3, policytool writes a warning at the top of the file not to edit it by hand, but real programmers still edit them by hand. Policy files are also used with JAAS, in which case their syntax changes slightly and you must edit them by hand at least until 1.4, when JAAS becomes integrated with the SDK. So first, well see how they look, and then well look at how they are created with policytool . Heres how a typical policy file might look: keystore {user.home}{}.keystore; Grant these permissions to code loaded from OReilly, regardless of whether the code is signed. grant codeBase http:www.oreilly.com { permission java.io.FilePermission tmp, read; permission java.lang.RuntimePermission queuePrintJob; }; Grant these permissions to code loaded from Sun but only if it is signed by sdo. grant signedBy sdo, codeBase http:www.sun.com { permission java.security.AllPermission; }; Grant these permissions to code signed by jra, no matter where it was loaded from grant signedBy jra { permission java.net.SocketPermission :1024−, accept, connect, listen, resolve; }; Grant these permissions to any code, no matter where it came from or whether it is signed grant { permission java.util.PropertyPermission java.version, read; }; Note how the policy file combines all the elements of the sandbox: the code sources the combination of signedBy and codeBase elements are associated with various permissions to create protection domains; the entire file is subject to the given keystore. The first line of this example tells the virtual machine to consult the keystore in the file HOME.keystore when it needs to check the certificates of entities that have signed code. The next four blocks of text define protection domains: code that is loaded from OReillys web site has permission to read files in tmp and to start a print job; code that is signed by sdo and loaded from Suns web site has permission to do anything it wants to; code that is signed by jra is able to operate on any nonprivileged socket; and all code is allowed to read the java.vendor system property. In each of these blocks, the syntax is the same: the word grant is followed by a code source and then a set of permissions enclosed by braces. The code source is composed of a codebase and a signer, either of which may be blank.Parts
» OReilly.Java.Security 2nd Edition
» What Is Security? Java Application Security
» The Java 2 Platform Software Used in This Book
» The Java Cryptography Extension
» The Java Secure Sockets Extension The Java Authentication and Authorization Service
» Applets, Applications, and Programs Anatomy of a Java Program
» Security Debugging Java Application Security
» Summary Java Application Security
» Elements of the Java Sandbox
» Permissions The Default Sandbox
» Keystores The Default Sandbox
» Code Sources The Default Sandbox
» Managing policy codebases The policytool
» Managing permissions The policytool
» Permissions Outside of Policy Files
» Comparison with Previous Releases
» Object Serialization and Memory Integrity
» Compiler Enforcement Enforcement of the Java Language Rules
» Inside the bytecode verifier
» Delayed bytecode verification The Bytecode Verifier
» Runtime Enforcement Enforcement of the Java Language Rules
» Controlling Bytecode Verification Comparisons with Previous Releases
» Summary Java Language Security
» Security Managers and the Java API
» Operating on the Security Manager
» Methods Relating to File Access
» Methods Relating to Network Access
» Methods Protecting the Java Virtual Machine
» Methods Protecting Program Threads
» Methods Protecting System Resources
» Methods Protecting Security Aspects
» System access Differences in the Security Manager Class
» Thread access Differences in the Security Manager Class
» Security access Differences in the Security Manager Class
» Summary The Security Manager
» The CodeSource Class The Access Controller
» The Permission Class Permissions
» The BasicPermission Class Permissions
» The Permissions Class Permissions
» Protection Domains The Access Controller
» Access Control Contexts The AccessController Class
» Guarded Objects The Access Controller
» Summary The Access Controller
» The Class Loader and Namespaces
» Class Loading Architecture Java Class Loaders
» Class Loader Classes Implementing a Class Loader
» The loadClass method Key Methods of the Class Loader
» The findClass method Key Methods of the Class Loader
» The defineClass methods Key Methods of the Class Loader
» Responsibilities of the Class Loader
» Step 1: Optionally call the checkPackageAccess method
» Step 2: Use the previously−defined class, if available
» Step 3: Defer class loading to the parent
» Step 4: Optionally call the checkPackageDefinition method
» Step 5: Read in the class bytes
» Step 6: Create the appropriate protection domain
» Steps 7−8: Define the class, verify it, and resolve it
» Using the SecureClassLoader Class
» Other Class Loaders Implementing a Class Loader
» Delegation Miscellaneous Class Loading Topics
» Loading Resources Miscellaneous Class Loading Topics
» Loading Libraries Miscellaneous Class Loading Topics
» Author Authentication The Need for Authentication
» Data Authentication The Need for Authentication
» Javas Role in Authentication
» Cryptographic Keys Cryptographic Engines
» Message Digests Cryptographic Engines
» Digital Signatures Cryptographic Engines
» Encryption Engines Cryptographic Engines
» Summary Introduction to Cryptography
» Components of the Architecture
» Choosing a Security Provider
» Implementing the Provider Class
» The Security Class and the Security Manager
» The Architecture of Engine Classes
» Diffie−Hellman keys Asymmetric Keys
» The KeyPair class Asymmetric Keys
» Using the KeyPairGenerator class
» Generating DSA keys The KeyPairGenerator Class
» Implementing a Key Pair Generator
» Using the KeyGenerator class
» Implementing a KeyGenerator class
» The SecretKeyFactory Class Key Factories
» Existing key specification classes
» The Certificate Class Certificates
» The CertificateFactory Class Certificates
» Advanced X509Certificate Methods
» Keys, Certificates, and Object Serialization
» Comparison with Previous Releases Summary
» Key Management Terms Key Management
» Generating a Certificate Request
» Importing a Certificate The keytool
» Creating a Certificate Entry
» Modifying Keystore Entries The keytool
» Deleting Keystore Entries The keytool
» Examining Keystore Data The keytool
» Miscellaneous Commands The keytool
» Using Certificates from Netscape
» Principals The KeyStore Class
» Secret Key Distribution Secret Key Management
» Secret Key Agreement Secret Key Management
» Using the Message Digest Class
» The Mac Class Secure Message Digests
» The DigestOutputStream Class Message Digest Streams
» The DigestInputStream Class Message Digest Streams
» The SignedObject Class The Signature Class
» Signing and Certificates The Signature Class
» Implementing a Signature Class
» Using the Cipher Class for EncryptionDecryption
» Initialization of a PBEWithMD5AndDES Cipher
» Using the Cipher Class for Key Wrapping
» Implementing the Cipher Class
» The CipherOutputStream Class Cipher Streams
» The CipherInputStream Class Cipher Streams
» Sealed Objects Cipher−Based Encryption
» Keystores and Truststores An Overview of SSL and JSSE
» JSSE Certificates An Overview of SSL and JSSE
» JSSE Socket Factories An Overview of SSL and JSSE
» SSL Server Sockets SSL Client and Server Sockets
» SSL Sockets SSL Client and Server Sockets
» Choosing an SSL Cipher Suite
» SSL Handshaking Miscellaneous SSL Issues
» JSSE Permissions Miscellaneous SSL Issues
» Verifying HTTPS Hosts The HTTPS Protocol Handler
» HTTPS Properties The HTTPS Protocol Handler
» Debugging JSSE SSL and HTTPS
» JAAS Overview Authentication and Authorization
» The LoginContext class The JAAS Setup Code
» The Subject class The JAAS Setup Code
» Login control flags Configuring Login Modules
» Sample login modules Configuring Login Modules
» Running the Example Simple JAAS Administration
» The name callback JAAS Callbacks
» The password callback JAAS Callbacks
» The choice callback JAAS Callbacks
» The confirmation callback JAAS Callbacks
» The language callback JAAS Callbacks
» ClientServer Authentication Advanced JAAS Topics
» Groups and Roles Advanced JAAS Topics
Show more