|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 6
Many access-control decisions are based in part on this property.
Permission classes are at the very core of Java security and represent access to various system resources such as files, sockets, and so on. A collection of permissions can be construed as a customizable security policy for an installation.
For example, permission may be given to read and write files in the /tmp directory. Permission classes are additive in that they represent approvals, but not denials. It's possible to explicitly
permit the reading of a particular file, but not to explicitly deny the reading of that file.
A number of permission classes are subclasses of the abstract java.security.Permission class, examples of which include FilePermission, AWTPermission, and even customized protections like SendMailPermission. For an exhaustive list of permissions, see Resources for a link to Li Gong's Inside Java 2 Platform Security.
It's possible to associate permissions with classes; however, it's more flexible to group classes into protection domains and associate permissions with those domains. A class's mapping to a domain occurs before the class is usable and is immutable thereafter. For instance, system classes can be effectively grouped under the system domain.
This relationship between the class and the permissions via the protection domain provides for flexible implementation mechanisms.
The numerous mappings of permissions to classes are collectively referred to as policy. A policy file is used to configure the policy for a particular implementation. It can be composed by a simple text editor
or using policytool, a tool bundled with the Software Development Kit (SDK), which we'll discuss in a future article.
As seen in Figure 4, the class java.lang.SecurityManager is at the focal point of authorization -- the implementation of the sandbox model in JDK 1.0 is a good example.
Prior to Java 2, SecurityManager was abstract; vendors had to create concrete implementations. In Java 2, SecurityManager is concrete, with a public constructor and appropriate checks in place to ensure that it can be invoked in an authorized
manner. SecurityManager consists of a number of check methods. For example, checkRead (String file) can determine read access to a file. The checkPermission (Permission perm, Object context) method can check to see if the requested access has the given permission based on the policy. This method is relegated to
the access controller in the default implementation. The access controller will raise an exception if the requested permission
cannot be granted. Refer to the "Sidebar 2: Security exceptions" for an overview of security exceptions.
The java.security.AccessController class is used for three purposes:
While the SecurityManager can be overridden, the static methods in AccessController are always available. If you wish a particular security check to always be invoked, regardless of which security manager
is in vogue, the AccessController methods should be called.