15.6 Access to System Resources

 <  Day Day Up  >  

Depending on the trust level on the deployed applications, one would have to protect malicious applications from accessing system resources, such as files and sockets, as well as resources within the container, such as internal data structures used by the container. The Java 2 security model can be used to achieve this level of security (see Chapter 8 on page 253). By granting appropriate Java permissions to trusted applications, as well as by checking for relevant permissions when a protected resource is being accessed, the container can protect sensitive resources. For example, if the container is configured to provide access to the class-loading mechanism or other internal classes only to trusted applications, the container can define and check for the relevant permissions before allowing access.

In addition to checking for permissions before accessing sensitive resources, the container should provide the right context when such checks are performed. For example, to maintain location transparency, so that local or remote enterprise beans behave the same way when permissions are checked, the container needs to limit the java.security.ProtectionDomain s on the call stack when authorization tests are performed (see Section 8.5 on page 265). As an example, let us consider two applications: ApplicationA and ApplicationB. Furthermore, let us assume that ApplicationA calls ApplicationB and that ApplicationB accesses a resource R1 requiring permission P1. When a call to the SecurityManager 's checkPermission() method is made to check whether P1 is granted, the java.security.AccessController class will check all the ProtectionDomain s on the call stack. In the case of local calls, ApplicationA (the caller) will be on the stack when such a check is performed. Therefore, both ApplicationA and ApplicationB will be on the call stack. However, if ApplicationA invokes ApplicationB remotely, ApplicationA will not be in the call stack and hence will not affect the authorization evaluation.

In order to maintain location transparency, the container needs to perform an AccessController.doPrivileged() call at the boundary where ApplicationA calls into ApplicationB, as shown in Figure 15.5. Invoking doPrivileged() sets up the environment such that ApplicationA's ProtectionDomain will not be on the stack, regardless of whether ApplicationA calls ApplicationB locally or remotely.

Figure 15.5. Accessing System Resources

graphics/15fig05.gif

Containers are also expected to insert necessary AccessController.doPrivileged() calls so that applications are not required to be granted a Permission for a task that the container is expected to perform. For instance, if the container has configuration information in a directory /config , the container should retrieve configuration information from the files in that directory without requiring that the permissions be granted to applications. In order to achieve this, containers should access such container-specific resources within an AccessController.doPrivileged() call, as shown in Figure 15.6.

Figure 15.6. Preventing Permission-Requirement Propagation

graphics/15fig06.gif

This ensures that only the container is required to be granted necessary Permissions to access the resources required to perform its tasks . Applications will not be required to be granted those Permissions.

 <  Day Day Up  >  


Enterprise Java Security. Building Secure J2EE Applications
Enterprise Javaв„ў Security: Building Secure J2EEв„ў Applications
ISBN: 0321118898
EAN: 2147483647
Year: 2004
Pages: 164

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net