Java in a Nutshell, 5th Edition [Electronic resources] نسخه متنی

6.5. Security for Everyone

Programmers, system administrators, and end users all have different
security concerns and, thus, different roles to play in the Java
security architecture.

6.5.1. Security for System Programmers

System
programmers are the people who define new Java APIs that allow access
to sensitive system resources. These programmers are typically
working with native methods that have unprotected access to the
system. They need to use the Java access control architecture to
prevent untrusted code from executing those native methods. To do
this, system programmers must carefully insert
SecurityManager calls at appropriate places in
their code. A system programmer may choose to use an existing
Permission subclass to govern access to the system
resources exposed by her API, or she may decide to define a
specialized subclass of Permission.

The system programmer carries a tremendous security burden: if she
does not perform appropriate access control checks in her code, she
compromises the security of the entire Java platform. The details are
complex and are beyond the scope of this book. Fortunately, however,
system programming that involves native methods is rare in Java;
almost all of us are application programmers who can simply rely on
the existing APIs.

6.5.2. Security for Application Programmers

Programmers who use the core Java
APIs and standard extensions but do not define new extensions or
write native methods can simply rely on the security efforts of the
system programmers who created those APIs. In other words, most of us
Java programmers can simply use the Java APIs and need not worry
about introducing security holes into the Java platform.

In fact, application programmers rarely have to use the access
control architecture. If you are writing Java code that may be run as
untrusted code, you should be aware of the restrictions placed on
untrusted code by typical security policies. Keep in mind that some
methods (such as methods that read or write files) can throw
SecurityException objects, but
don't feel you must write your code to catch these
exceptions. Often, the appropriate response to a
SecurityException is to allow it to propagate
uncaught so that it terminates the application.

Sometimes, as an application programmer,
you want to write an application (such as an applet viewer) that can
load untrusted classes and run them subject to access control checks.
To do this in Java 1.2 and later, you must first install a security
manager:

System.setSecurityManager(new SecurityManager());

You then use java.net.URLClassLoader to load the
untrusted classes. URLClassLoader assigns a
default set of safe permissions to the classes it loads, but in some
cases you may want to modify the permissions granted to the loaded
code through the Policy and
PermissionCollection classes.

6.5.3. Security for System Administrators

In Java 1.2 and later, system
administrators are responsible for defining the default security
policy for the computers at their site. The default policy is stored
in the file

lib/security/java.policy in the Java
installation. A system administrator can edit this text file by hand
or use the

policytool program from Sun to edit
the file graphically.

policytool is the
preferred way to define policies, so the syntax of the underlying
policy file is not documented in this book.

The default

java.policy file defines a policy that is much
like the policy of Java 1.0 and Java 1.1: system classes and
installed extensions are fully trusted, while all other code is
untrusted and only allowed a few simple permissions. While this
default policy is adequate for many purposes, it may not be
appropriate for all sites. For example, at some organizations, it may
be appropriate to grant extra permissions to code downloaded from a
secure intranet.

In order to define
effective security policies, a system administrator must understand
the various Permission subclasses of the Java
platform, the target and action names they support, and the security
implications of granting any particular permission. These topics are
explained well in a document titled "Permissions in
the Java 2 Standard Edition Development Kit (JDK),"
which is available online at http://java.sun.com/j2se/1.5.0/docs/guide/security/permissionsl.

6.5.4. Security for End Users

Most end users do not have to
think about security at all: their Java programs should simply run in
a secure way with no intervention from them. Some sophisticated end
users may want to define their own security policies, however. An end
user can do this by running

policytool himself
to define personal policy files that augment the system policy. The
default personal policy is stored in a file named

.java.policy in the user's home
directory. By default, Java loads this policy file and uses it to
augment the system policy file.

In Java 1.2 and later, a user can specify an additional policy file
to use when starting up the Java interpreter. To do so, you use the
-D option to define the
java.security.policy property. For example:

C:\> java -Djava.security.policy
= 
policyfile  
UntrustedApp 

This line runs the class
UntrustedApp after augmenting the default system
and user policies with the policy specified in the file or URL
policyfile. To replace the system and user
policies instead of augmenting them, use a double equals sign in the
property specification:

C:\> java -Djava.security.policy= =
policyfile  UntrustedApp

Note, however, that specifying a
policy file is useful only if there is a
SecurityManager installed. If a user
doesn't trust an application, he presumably
doesn't trust that application to voluntarily
install its own security manager. In this case, he can define the
java.security.manager
system property:

C:\> java -Djava.security.manager -Djava.security.policy
= 
policyfile  
\  UntrustedApp

The value of this property does not matter; simply defining it is
enough to tell the Java interpreter to automatically install a
default SecurityManager object that subjects an
application to the
access control policies described in the
system, user, and java.security.policy policy
files.