Accessing Native methods from a Java Applet
by Sanket Bakshi, s.bakshi@ebsolutech.com |
|
Previous
section: Issues using JNI with
Applets
1.
Evolution of the Java Sandbox
2.
The Class Loader and Class File Verifier
The Java
Sandbox has evolved a lot since its first version.
The Java 1.0 Sandbox
The
original security model provided by the Java existed in order to provide a very
restricted environment in which to run untrusted code obtained from the open
network. The local was trusted to have full access to vital system resources
(such as the file system) while downloaded remote code (an applet) was not
trusted and can access only the limited resources provided inside the sandbox.
This sandbox model is illustrated in the figure below.
The sandbox model was deployed through the
Java Development Kit (JDK), and was generally adopted by applications built
with JDK 1.0, including Java-enabled web browsers.
Overall security is enforced through a number
of mechanisms. First of all, the language is designed to be type-safe and easy
to use. The hope is that the burden on the programmer is such that the
likelihood of making subtle mistakes is lessened compared with using other
programming languages such as C or C++. Language features such as automatic
memory management, garbage collection, and range checking on strings and arrays
are examples of how the language helps the programmer to write safe code.
Second, compilers and a byte code verifier
ensure that only legitimate Java byte codes are executed. The byte code
verifier, together with the Java Virtual Machine, guarantees language safety at
run time.
Moreover, a classloader defines a local name
space, which can be used to ensure that an untrusted applet cannot interfere
with the running of other programs.
Finally, access to crucial system resources
is mediated by the Java Virtual Machine and is checked in advance by a
SecurityManager class that restricts the actions of a piece of untrusted code
to the bare minimum.
The Java 1.1 Sandbox
The JDK1.0 Sandbox imposed restrictions on any
code that was downloaded. Many times, the downloaded code required for
performing certain activities. For the same purpose, the JDk1.1 Sandbox induced
the concept of Signed applets. In that release, a correctly digitally signed
applet is treated as if it is trusted local code if the signature key is
recognized as trusted by the end system that receives the applet. Signed
applets, together with their signatures, are delivered in the JAR (Java
Archive) format. However, the unsigned applets run in the Sandbox.
The Java 1.2 Sandbox
The
problem with the JDK1.1 Sandbox is that a signed applet is allowed full access
to the system. This is undesirable because an applet designed for a specific
purpose should be allowed to access only those resources, which are needed by
it.
The
following figure illustrates the JDK1.2 Sandbox model –
The
JDK1.2 Sandbox addresses the above problem and introduces following new
capabilities –
Fine-grained
access control.
This
capability existed in the JDK from the beginning, but to use it, the
application writer had to do substantial programming (e.g., by subclassing and
customizing the SecurityManager and ClassLoader classes). The HotJava browser
1.0 is such an application, as it allows the browser user to choose from a
small number of different security levels.
However,
such programming is extremely security-sensitive and requires sophisticated
skills and in-depth knowledge of computer security. The new architecture will
make this exercise simpler and safer.
Easily
configurable security policy.
Once
again, this capability existed previously in the JDK but was not easy to use.
Moreover, writing security code is not straightforward, so it is desirable to
allow application builders and users to configure security policies without
having to program.
Easily
extensible access control structure.
Up
to JDK 1.1, in order to create a new access permission, you had to add a new check method to the SecurityManager class. The new
architecture allows typed permissions (each representing an access to a system
resource) and automatic handling of all permissions (including
yet-to-be-defined permissions) of the correct type. No new method in the
SecurityManager class needs to be created in most cases. (In fact, we have so
far not encountered a situation where a new method must be created.)
Extension
of security checks to all Java programs, including applications as well as
applets.
There
is no longer a built-in concept that all local code is trusted. Instead, local
code (e.g., non-system code, application packages installed on the local file
system) is subjected to the same security control as applets, although it is
possible, if desired, to declare that the policy on local code (or remote code)
be the most liberal, thus enabling such code to effectively run as totally
trusted. The same principle applies to signed applets and any Java application.
In the
Sandbox, the class loader is the first point, which takes a defensive approach.
This is because, it is the class loader that brings the code into the JVM. The
class loader contributes to Java Security in the following ways –
o Preventing
malicious code from interfering with benevolent code
o Guarding borders
of trusted class libraries
o Placing code into
categories called Protection Domains that will determine the actions the code
can do.
The
other thing that works in conjunction with the Class Loader to build the Java
Sandbox is the Class File Verifier. The Class File Verifier ensures that the
loaded class files have a proper internal structure and that they are
consistent. If the Class File Verifier encounters any problem, it throws an
exception. The class verifier is required, as the virtual machine cannot
determine how a particular class file was created. A class file is simply a
sequence of bytes and can be created by a well-meaning compiler or even by a
cracker who can compromise the integrity of the virtual machine. Therefore, the
class file verifier has to be present to make sure that the class files are
safe to use.
The Java
Security manager works for protecting the assets that are external to the
virtual machine. The Security Manager is a central point for access control
within a Java Virtual Machine. The Security manager defines the outer
boundaries of the sandbox. The Security Manager is customizable and can thus
define custom policies for the applications. The Java API enforces the custom
policies by asking the Security manager for available privileges at runtime.
Thus any potentially unsafe action like reading or writing to the file etc.
will not be performed unless the Security Manager offers the consent. Thus no
action will be performed which is forbidden under the security policy. The
application by default does not have a security manager. Whereas, any
downloaded code that runs under the JVM, is monitored by the Security Manager.
The Security Policies can be customized using the java policy file (discussed
afterwards).
The use
of the Java policy file gives a fine control over the security policies. The
policies can be edited for customization. The Policy Tool provided by the JDK
is used to edit the policies. The privileges can be given to a certain code
based on the following two attributes –
o CODEBASE
o Signed By
The
CODEBASE attribute lets you specify the permissions based on the CODEBASE of
the code. A code being executed from a certain CODEBASE can be given some
additional privileges.
The
‘Signed By’ attribute helps specifying the privileges based on the alias of the
signer. (The code has to be digitally signed)
Following
is a excerpt of a policy file –
CODEBASE
based
grant
codeBase "file:C:/Documents and Settings/sanketb/Local Settings/Temp/*"
{
permission java.security.AllPermission;
};
Signed By based
grant
signedBy "sanket" {
permission java.lang.RuntimePermission
"stopThread";
permission java.net.SocketPermission
"localhost:1024-", "listen";
};
Next section: The Java Plug-in
Table of Contents
©
2001 – EBSolute Technologies