United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4286238 exitVM security property not working
JDK-4286238 : exitVM security property not working

Details
Type:
Bug
Submit Date:
1999-10-29
Status:
Resolved
Updated Date:
2001-08-02
Project Name:
JDK
Resolved Date:
2001-08-02
Component:
docs
OS:
windows_nt,solaris_7
Sub-Component:
guides
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
1.3.0
Fixed Versions:
1.4.0 (beta2)

Related Reports
Duplicate:

Sub Tasks

Description

Name: sg39081			Date: 10/29/99


It is my belief that this is a bug, as it allows code downloaded
into an application to mount a DOS attack by simply killing the
application. This is documented in the JDK API, but does not seem
to work like the rest of the security checks.

//In the code, I don't setup a security manager, as this is done
//by specifying the java.security.manager property at the command
//line.

//Note: The JavaDoc for the JDK states in Runtime.exit() that:-
  "throws SecurityException - If a security manager is present and its
  checkExit method does not permit exiting with the specified status"

This means that a call to System.exit(0) which merely delegates to
Runtime.exit() should first check for the appropriate permissions and
throw a security exception or AccessControlException if that permission
does not exit.

   public static void main( String[] args ) throws Exception {
      //We could setup a security manager here, or do it on the
      //cmd line.
      //Example of doing it here.
      //System.setSecurityManager( new SecurityManager() );

      //This fails if the appropriate permission is left out of
      //mypolicy. The failure is an AccessControlException.
      System.getProperty("java.home", "not specified");
      //This should fail since that permission is not granted.
      System.exit( 0 );
   }

//Here, we specify that the default security manager should be used, and
//that the policies should include the "mypolicy" file.
Cmd Line> java -Djava.security.policy=mypolicy -Djava.security.manager tests.SecurityTest

//This is the policy file. Note the lack of a permission, namely,
// permission java.lang.RuntimePermission "exitVM";
//According to the docs, this should result in a security exception
//being thrown when the appropriate System.exit() method is called.
>policy file = mypolicy
grant codeBase "file:/d:/work/java/-" {
  permission java.util.PropertyPermission "java.*", "read";
};

>java -version
java version "1.3beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3beta-O)
Java(TM) HotSpot Client VM (build 1.3beta-O, mixed mode)

>java -fullversion
java full version "1.3beta-O"
(Review ID: 96704) 
======================================================================

                                    

Comments
EVALUATION


mayank.upadhyay@eng 1999-11-01

In sun/misc/Launcher.java the inner class AppClassLoader grants the exitVM
permission in its getPermissions() method. While this permission may be
desirable during class loading it should not remain in effect later on.

sun.applet.AppletClassLoader does not do the same.

mayank.upadhyay@eng 2000-02-07

This will be reclassified as a doc bug. See the following:

=================

	I don't agree with the bug evaluation.  I think it was intended
that classes defined by the Application/System class loader would be
granted exitVM permission -- not just temporarily during class loading.
I believe it was felt that applications should be able to terminate
themselves but that code loaded from other loader instances such as
AppletClassLoader or other URLClassLoaders should not be granted this
permission by default.


	The bug report claims:
	
> It is my belief that this is a bug, as it allows code downloaded
> into an application to mount a DOS attack by simply killing the
> application.

	However, I doubt that this is actually true and the example
given in the bug description only shows an application exiting.
I think the bug submitter was confused about why the System.exit() was
succeeding. It wasn't because SecurityManager.checkExit() is broken,
instead it is because we explicitly grant permission to exit the
VM to any class loaded from the application class path. Downloaded
code would normally be loaded by a class loader other than
the system/application class loader.

	This should probably be closed as "not a bug" or should be
mutated into a bug against our javadoc to note that "exitVM" permission
is automatically granted to all code loaded from the application class
path.  We make a similar mention about auto-granted permissions in
java.io.FilePermission and java.net.URLClassLoader. Since the class
which grants the permissions, sun.misc.Launcher.AppClassLoader, is not
public we should probably then add the note to RuntimePermission.



	Jeff
==================


Is this workarrounds ok? There still the requirement to "withdraw"
some of the default permissions granted to Java application. The
attached code is my workarround to create so called a "anti-exitVM"
permisstion. The code is for the evaluation, if possible.
Hope we have a chance to discussion this issue with someone there.

###@###.### 2002-04-17
================================
                                     
2002-04-17
WORK AROUND



Name: sg39081			Date: 10/29/99


Subclass SecurityManager and overload checkExit method.
======================================================================
                                     
2004-06-11
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
merlin

FIXED IN:
merlin-beta2

INTEGRATED IN:
merlin-beta2


                                     
2004-06-14



Hardware and Software, Engineered to Work Together