Java Security Model: Java Protection Domains

Question

1.     Policy Configuration
Until now, security policy was hard-coded in the security manager used by Java applications. This gives us the effective but rigid Java sandbox for applets.A major enhancement to the Java sandbox is the separation of policy from mechanism. Policy is now expressed in a separate, persistent format. The policy is represented in simple ascii, and can be modified and displayed by any tools that support the policy syntax specification. This allows:
o     Configurable policies -- no longer is the security policy hard-coded into the application.
o     Flexible policies -- Since the policy is configurable, system administrators can enforce global polices for the enterprise. If permitted by the enterprise's global policy, end-users can refine the policy for their desktop.
o     Fine-grain policies -- The policy configuration file uses a simple, extensible syntax that allows you to specify access on specific files or to particular network hosts. Access to resources can be granted only to code signed by trusted principals.
o     Application policies -- The sandbox is generalized so that applications of any stripe can use the policy mechanism. Previously, to establish a security policy for an application, an developer needed to implement a subclass of the SecurityManager, and hard-code the application's policies in that subclass. Now, the application can make use of the policy file and the extensible Permission object to build an application whose policy is separate from the implementation of the application.
o     Extensible policies -- Application developers can choose to define new resource types that require fine-grain access control. They need only define a new Permission object and a method that the system invokes to make access decisions. The policy configuration file and policy tools automatically support application-defined permissions. For example, an application could define a CheckBook object and a CheckBookPermission.
2.     X.509v3 Certificate APIs
Public-key cryptography is an effective tool for associating an identity with a piece of code. JavaSoft is introducing API support in the core APIs for X.509v3 certificates. This allows system administrators to use certificates from enterprise Certificate Authorities (CAs), as well as trusted third-party CAs, to cryptographically establish identities.
3.     Protection Domains
The central architectural feature of the Java security model is its concept of a Protection Domain. The Java sandbox is an example of a Protection Domain that places tight controls around the execution of downloaded code. This concept is generalized so that each Java class executes within one and only one Protection Domain, with associated permissions.
When code is loaded, its Protection Domain comes into existence. The Protection Domain has two attributes - a signer and a location. The signer could be null if the code is not signed by anyone. The location is the URL where the Java classes reside. The system consults the global policy on behalf of the new Protection Domain. It derives the set of permissions for the Protection Domain based on its signer/location attributes. Those permissions are put into the Protection Domain's bag of permissions.
4.     Access Decisions
Access decisions are straightforward. When code tries to access a protected resource, it creates an access request. If the request matches a permission contained in the bag of permissions, then access is granted. Otherwise, access is denied. This simple way of making access decisions extends easily to application-defined resources and access control. For example, the banking application allows access to the CheckBook only when the executing code holds the appropriate CheckBookPermission.
Sandbox model for Security
Java is supported in applications and applets, small programs that spurred Java's early growth and are executable in a browser environment. The applet code is downloaded at runtime and executes in the context of a JVM hosted by the browser. An applet's code can be downloaded from anywhere in the network, so Java's early designers thought such code should not be given unlimited access to the target system. That led to the sandbox model -- the security model introduced with JDK 1.0.
The sandbox model deems all code downloaded from the network untrustworthy, and confines the code to a limited area of the browser -- the sandbox. For instance, code downloaded from the network could not update the local file system. It's probably more accurate to call this a "fenced-in" model, since a sandbox does not connote strict confinement.
While this may seem a very secure approach, there are inherent problems. First, it dictates a rigid policy that is closely tied to the implementation. Second, it's seldom a good idea to put all one's eggs in one basket -- that is, it's unwise to rely entirely on one approach to provide overall system security.
Security needs to be layered for depth of defense and flexible enough to accommodate different policies -- the sandbox model is neither.
java.security.ProtectionDomain
This class represents a unit of protection within the Java application environment, and is typically associated with a concept of "principal," where a principal is an entity in the computer system to which permissions (and as a result, accountability) are granted.
A domain conceptually encloses a set of classes whose instances are granted the same set of permissions. Currently, a domain is uniquely identified by a CodeSource, which encapsulates two characteristics of the code running inside the domain: the codebase (java.net.URL), and a set of certificates (of type java.security.cert.Certificate) for public keys that correspond to the private keys that signed all code in this domain. Thus, classes signed by the same keys and from the same URL are placed in the same domain.
A domain also encompasses the permissions granted to code in the domain, as determined by the security policy currently in effect.
Classes that have the same permissions but are from different code sources belong to different domains.
A class belongs to one and only one ProtectionDomain.
Note that currently in Java 2 SDK, v 1.2, protection domains are created "on demand" as a result of class loading. The getProtectionDomain method in java.lang.Class can be used to look up the protection domain that is associated with a given class. Note that one must have the appropriate permission (the RuntimePermission "getProtectionDomain") to successfully invoke this method.
Today all code shipped as part of the Java 2 SDK is considered system code and run inside the unique system domain. Each applet or application runs in its appropriate domain, determined by its code source.
It is possible to ensure that objects in any non-system domain cannot automatically discover objects in another non-system domain. This partition can be achieved by careful class resolution and loading, for example, using different classloaders for different domains. However, SecureClassLoader (or its subclasses) can, at its choice, load classes from different domains, thus allowing these classes to co-exist within the same name space (as partitioned by a classloader).
jarsigner and keytool
example : cd D:\EicherProject\EicherWEB\Web Content jarsigner -keystore eicher.store source.jar eichercert
The javakey tool from JDK 1.1 has been replaced by two tools in Java 2.
One tool manages keys and certificates in a database. The other is responsible for signing and verifying JAR files. Both tools require access to a keystore that contains certificate and key information to operate. The keystore replaces the identitydb.obj from JDK 1.1. New to Java 2 is the notion of policy, which controls what resources applets are granted access to outside of the sandbox (see Chapter 3).
The javakey replacement tools are both command-line driven, and neither requires the use of the awkward directive files required in JDK 1.1.x. Management of keystores, and the generation of keys and certificates, is carried out by keytool. jarsigner uses certificates to sign JAR files and to verify the signatures found on signed JAR files.
Here we list simple steps of doing the signing. We assume that JDK 1.3 is installed and the tools jarsigner and keytool that are part of JDK are in the execution PATH. Following are Unix commands, however with proper changes, these could be used in Windows as well.
1. First generate a key pair for our Certificate:
keytool -genkey -keyalg rsa -alias AppletCert
2. Generate a certification-signing request.
keytool -certreq -alias AppletCert > CertReq.pem
3. Send this CertReq.pem to VeriSign/Thawte webform. Let the signed reply from them be SignedCert.pem.
4. Import the chain into keystore:
keytool -import -alias AppletCert -file SignedCert.pem
5. Sign the CyberVote archive �TeleVote.jar�:
jarsigner TeleVote.jar AppletCert
This signed applet TeleVote.jar can now be made available to the web server. For testing purpose we can have our own test root CA. Following are the steps to generate a root CA by using openssl.
1. Generate a key pair for root CA:
openssl genrsa -des3 -out CyberVoteCA.key 1024
2. Generate an x509 certificate using the above keypair:
openssl req -new -x509 -days key CyberVoteCA.key -out CyberVoteCA.crt
3. Import the Certificate to keystore.
keytool -import -alias CyberVoteRoot -file CyberVoteCA.crt
Now, in the step 3 of jar signing above, instead of sending the request certificate to VeriSign/Thawte webform for signing, we 365 - can sign using our newly created root CA using this command:
openssl x509 -req -CA CyberVoteCA.crt -CAkey CyberVoteCA.key -days 365 -in CertReq.pem -out SignedCert.pem �Cacreateserial
However, our test root CA has to be imported to the keystore of voter�s web browser in some way. [This was not investigated. We used some manual importing procedure which is not recommended way]
The Important Classes
The MessageDigest class, which is used in current CyberVote mockup system (see section 2), is an engine class designed to provide the functionality of cryptographically secure message digests such as SHA-1 or MD5. A cryptographically secure message digest takes arbitrary-sized input (a byte array), and generates a fixed-size output, called a digest or hash. A digest has the following properties:
� It should be computationally infeasible to find two messages that hashed to the same value.
� The digest does not reveal anything about the input that was used to generate it.
Message digests are used to produce unique and reliable identifiers of data. They are sometimes called the "digital fingerprints" of data.
The (Digital)Signature class is an engine class designed to provide the functionality of a cryptographic digital signature algorithm such as DSA or RSA with MD5. A cryptographically secure signature algorithm takes arbitrary-sized input and a private key and generates a relatively short (often fixed-size) string of bytes, called the signature, with the following properties:
� Given the public key corresponding to the private key used to generate the signature, it should be possible to verify the authenticity and integrity of the input.
� The signature and the public key do not reveal anything about the private key.
A Signature object can be used to sign data. It can also be used to verify whether or not an alleged signature is in fact the authentic signature of the data associated with it.
----Cheers
---- Dinesh Vishwakarma

Answer 1

Hi,
these concepts are used and implemented in jGuard(www.jguard.net) which enable easy JAAS integration into j2ee webapps across application servers.
cheers,
Charles(jGuard team).