# Re: ClassLoader security issues

Marianne Mueller (Marianne.Mueller@Eng)
Mon, 16 Mar 1998 17:37:27 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Jan Luehe: "Re: Download from Italy"
- Previous message: Marianne Mueller: "Re: Problems reading a server file through the internet"

    Date: Mon, 16 Mar 1998 17:37:27 -0800 (PST)

    From: Marianne Mueller <Marianne.Mueller@Eng>

    Subject: Re: ClassLoader security issues

    To: rkaveti@hotmail.com

> From: "Rajesh Kaveti" <rkaveti@hotmail.com>
> To: mrm@puffin.eng.sun.com
> Subject: ClassLoader security issues
> Date: Sun, 15 Mar 1998 16:22:50 PST
>
> Hi
>
> I am trying to create a new classloader in a applet. You mentioned the
> following in one of the replies in one of the FAQ
>
> "We know that people want more flexibility with downloaded applets, and
> for the next release, we are working on the infrastructure that would
> allow more flexibility.See http://java.sun.com/security/handout.html for
> a brief summary of features"
>
> Would you know if we can instantiate a class loader in JDK1.1 or JDK1.2
>
> Any help would be greatly appreciated.
>
> Thanks
>
> Rajesh

You can do this in JDK1.2, by granting permission in a policy file.
The policy file is a simple ascii file that is separate from the JVM.
Typically there is a system-wide policy file installed in $JDK/lib/security,
and if allowed by the overall JVM configuration, user-specific policy
files located in ~user/.java.policy are also used in addition to the
system-wide policy file.

The permission that you grant in your case is specifically for creating a
classloader.
You can either grant this permission to all code, or to code from a
certain URL, or to code that is signed by a particular signer, or both.
Examples of the policy file syntax are at the end of this message.

When the JVM starts up, it is initialized by the policy file(s).
Then, when your code is loaded into the JVM, it is assigned a set of
permissions, according to what the prevailing policy is, and where your
code comes from and who signed it. Finally, at runtime, when an
access decision needs to be made ("does this code have permission to
create a classloader?") the runtime system checks to see if your code
holds the permission to do the potentially restricted thing it wants
to do.

Below are 4 policy file entries that demonstrate what the syntax looks like,
for the classloader example. There are several dozen permission objects
(file permission, awt permissions, other runtime permissions, etc.)

You can read more about how Policy & Permission works from the java.sun.com
web site,
http://java.sun.com/products/jdk/1.2/docs/guide/security/

Please note that the docs on our website right now reflect JDK 1.2beta2,
and JDK 1.2 beta3 should be available pretty soon, with updated documentation.

--Marianne

-----Policy File Entry Examples-----

// let any code create a class loader
grant {
permission java.lang.RuntimePermission "createClassLoader";
};

// let code from a certain URL create a class loader
grant codeBase "http://java.sun.com/security/examples" {
permission java.lang.RuntimePermission "createClassLoader";
};

// let code signed by JavaSoft create a class loader
grant signedBy "javasoft" {
permission java.lang.RuntimePermission "createClassLoader";
};

// let code signed by JavaSoft that comes from JavaSoft's web site
//create a class loader
grant signedBy "javasoft", codeBase "http://java.sun.com/security/examples" {
permission java.lang.RuntimePermission "createClassLoader";
};

- Next message: Jan Luehe: "Re: Download from Italy"
- Previous message: Marianne Mueller: "Re: Problems reading a server file through the internet"