How to configure Applet Security via the java.policy File

mikesung99
mikesung99 used Ask the Experts™
on
Hi,

We have developed a simple Java Applet that creates a TCP Port to listen on 1035 and also fires socket request messages to Port 1034 (which is the listening port of a local service) All TCP communications will be completed throught local host.

The Applet does not use a Java signed certificate as the solution is to designed to work on a local intranet.

However when we start up the applet and we try to fire a test message to the listening port of the applet 1035- the following error was outputted to the Java Console:

Exception in thread "Thread-11" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:2046 accept,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkAccept(Unknown Source)
      at java.net.ServerSocket.implAccept(Unknown Source)
      at java.net.ServerSocket.accept(Unknown Source)
      at tntcctapplet.Listner_Class.Listener_Loop(Listner_Class.java:128)
      at tntcctapplet.Listner_Class.run(Listner_Class.java:73)

From the Java Policy (securiy) on the clents machine the following parameters is set:

permission java.net.SocketPermission "localhost:1024-", "listen";

We initially thought this was fine as the Port range covered our required Ports i.e. 1035. However we are unsure why the error message states SocketPermission 127.0.0.1:2046 accept,resolve) referencing Port 2046, when we are firing a test message to Port 1035...........

We followed to modify the Java Policy to indicate the following:

      permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";

This removed all the Java Socket communication issues but was a concern,  as we appear to have unlocked all the Ports to potential malicious actions.

Therefore we tried to restrict the Port Range in the Java.Policy as illustrated below:

      permission java.net.SocketPermission "127.0.0.1:1024-1035", "listen, accept, connect, resolve";

Based on the above's narrow range, when we tried to Test by firing to port 1035 again, we get thefollowingbelow:-

Exception in thread "Thread-11" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:4915 accept,resolve)

How do we restrict the Port Range used by Acces Controland why is there an error message relating to the seeminglyrandom port

The solution is created under Java Version 1.4 and JRE environment is 1.6.

Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Mick BarryJava Developer
Top Expert 2010

Commented:
you would be better off signing the jars instead of using the policy file
policy file approach would require all your users to also change their policy file
Mick BarryJava Developer
Top Expert 2010

Commented:
error occurs because a random port is opened to handle incoming connections.
Top Expert 2004

Commented:
Hi mikesung99,

To create signed applet jar file. Here is the instruction.
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html

Hope this help,
Sompol
Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Mick BarryJava Developer
Top Expert 2010

Commented:
Mick BarryJava Developer
Top Expert 2010

Commented:
>  However we are unsure why the error message states SocketPermission 127.0.0.1:2046 accept,resolve) referencing Port 2046, when we are firing a test message to Port 1035...........

because as well as listening permission, you also need perms to create a new socket when a connection is received

Why are you using an applet and not an application?

Top Expert 2016

Commented:
>>
This removed all the Java Socket communication issues but was a concern,  as we appear to have unlocked all the Ports to potential malicious actions.
>>

Only to your applet if you specify only its codebase

Author

Commented:
Thanks for the feedback -  we are reviewing the option of a Signed Applet.

CEHJ:
>>
Only to your applet if you specify only its codebase
>>

CEHJ can you provide more information to your above comment please.....
Top Expert 2016

Commented:
Permissions can be granted to a codebase:

grant codeBase "http://www.yourdomain.com/-" {
      permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
};

Author

Commented:
Thanks for the response and example of code base.

>>
grant codeBase "http://www.yourdomain.com/-" {
      permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
>>

I tried your example but the solution still fails on permission.  We use a internal test IIS enivironment on : 192.168.0.79 to deploy our Applets and we browe through the intranet.

Brows to the address : http://192.168.0.79/Test/TestApplet.html

I added the code base to the clients - Java Policy as illustrated belwow:

>>
grant codeBase "file:${{java.ext.dirs}}/*" {
      permission java.security.AllPermission;
};

grant codeBase "http://192.168.0.79/" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
};
grant {
        permission java.net.SocketPermission "127.0.0.1:1024-", "listen";      
>>

To ensure that all Applets deployed from "192,168,0,79" wiill not have any Perms issue.

Please advice.....



Mick BarryJava Developer
Top Expert 2010

Commented:
> I tried your example but the solution still fails on permission.

It won't make any difference
Mick BarryJava Developer
Top Expert 2010

Commented:
>   permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";

you don't need listen permissions here

>         permission java.net.SocketPermission "127.0.0.1:1024-", "listen";      

you only need to listen on a single port


should be more like:

grant codeBase "http://192.168.0.79/" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, resolve";
};
grant codeBase "http://192.168.0.79/"  {
        permission java.net.SocketPermission "127.0.0.1:1035", "listen";      


though my policy file skills are fairly rusty, its been a long time since we needed to fiddle with security policy settings :)

Author

Commented:
Hi,

Thanks for the examples of the same code base I updated my Java.Policy as illustrated below

>> 
grant codeBase "http://192.168.0.79/*"  {
        permission java.net.SocketPermission "127.0.0.1:1035", "listen";      
};
>>
grant codeBase "http://192.168.0.79/*" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, resolve";
};
>>

When I browse to the test Applet - on 79 the Applet Fails on Permission in opening Port 1034

I receive the error below:

>>
AccessControlException: access denied (java.lang.RuntimePermission exitVM.1)
>>

Am I'm setting the Policy incorrectly...
Mick BarryJava Developer
Top Expert 2010

Commented:
> Am I'm setting the Policy incorrectly...

looks like it.

your problem now is you are calling System.exit() somewhere in your applet.
An applet should not exit.

Author

Commented:
Please find the contents of our client Java.Policy below:

>>

// Standard extensions get all permissions by default

grant codeBase "file:${{java.ext.dirs}}/*" {
      permission java.security.AllPermission;
};


grant codeBase "http://192.168.0.79/" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, resolve";
};

grant codeBase "http://192.168.0.79/"  {
        permission java.net.SocketPermission "127.0.0.1:1035", "listen";      
};


// default permissions granted to all domains

grant {
      // Allows any thread to stop itself using the java.lang.Thread.stop()
      // method that takes no argument.
      // Note that this permission is granted by default only to remain
      // backwards compatible.
      // It is strongly recommended that you e sources
      // that you specify, because Thread.stop() is potentiaeither remove this permission
      // from this policy file or further restrict it to codlly unsafe.
      // See "http://java.sun.com/notes" for more information.
      permission java.lang.RuntimePermission "stopThread";

      // allows anyone to listen on un-privileged ports
      
      permission java.util.PropertyPermission "java.version", "read";
      permission java.util.PropertyPermission "java.vendor", "read";
      permission java.util.PropertyPermission "java.vendor.url", "read";
      permission java.util.PropertyPermission "java.class.version", "read";
      permission java.util.PropertyPermission "os.name", "read";
      permission java.util.PropertyPermission "os.version", "read";
      permission java.util.PropertyPermission "os.arch", "read";
      permission java.util.PropertyPermission "file.separator", "read";
      permission java.util.PropertyPermission "path.separator", "read";
      permission java.util.PropertyPermission "line.separator", "read";

      permission java.util.PropertyPermission "java.specification.version", "read";
      permission java.util.PropertyPermission "java.specification.vendor", "read";
      permission java.util.PropertyPermission "java.specification.name", "read";

      permission java.util.PropertyPermission "java.vm.specification.version", "read";
      permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
      permission java.util.PropertyPermission "java.vm.specification.name", "read";
      permission java.util.PropertyPermission "java.vm.version", "read";
      permission java.util.PropertyPermission "java.vm.vendor", "read";
      permission java.util.PropertyPermission "java.vm.name", "read";
};

>>

Thanks....


Mick BarryJava Developer
Top Expert 2010

Commented:
looks good

Author

Commented:
Hi,

When the Applet First Starts up - We will attempt to open the Socket 1035 if this fails the Applet will  System.exit() as illustrated below:

>>
      try
      {
      svrSocket = new ServerSocket(port, qSize);
        svrSocket.setSoTimeout(0);
      }
      catch (Exception /* IOException */ e)
      {
        // Error
        Listen = false;
        System.exit(1);
      }
>>

From the Java Policy we stated to allow Port 1035 to listen but it's failing to Open the Port... Any ideas.
Mick BarryJava Developer
Top Expert 2010

Commented:
>         System.exit(1);

get rid of that, you don't want to shutdown the vm becuase its running inside the browser so you need to let it manage the vm.

instead switch to a different page
or put up a message stating the issue

      catch (Exception /* IOException */ e)
      {
        // Error
        Listen = false;
        e.printStackTrace();
      }

and tell me what gets displayed in the console

Author

Commented:
Please the error from the JVM console:

>>
basic: Applet loaded.
basic: Applet resized and added to parent container
basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 561800 us, pluginInit dt 2149068 us, TotalTime: 2710868 us
basic: Applet initialized
basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@1006d75
basic: Applet made visible
basic: Starting applet
basic: completed perf rollup
basic: Applet started
basic: Told clients applet is started

network: Disconnect connection to http://127.0.0.1/Test/TestApplet/Listner_Class.class
Exception in thread "Thread-11" java.security.AccessControlException: access denied (java.lang.RuntimePermission exitVM.1)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkExit(Unknown Source)
      at java.lang.Runtime.exit(Unknown Source)
      at java.lang.System.exit(Unknown Source)
      at TestApplet.Listner_Class.Listener_Loop(Listner_Class.java:124)
      at TestApplet.Listner_Class.run(Listner_Class.java:73)
>>

Thanks...

Mick BarryJava Developer
Top Expert 2010

Commented:
your still calling exit() you need to remove it

Author

Commented:
Hi,

I've  just double checked that exit() was removed from the code, recompiled and then deployed. However, I still seem to get a security error

>>

security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.
security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws
security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws
security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws,com.sun.deploy
security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws,com.sun.deploy
security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
security: property package.definition value null
security: property package.definition new value com.sun.javaws
security: property package.definition value com.sun.javaws
security: property package.definition new value com.sun.javaws,com.sun.deploy
security: property package.definition value com.sun.javaws,com.sun.deploy
security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp
security: property package.access value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws,com.sun.deploy,com.sun.jnlp
security: property package.access new value sun.,com.sun.xml.internal.ws.,com.sun.xml.internal.bind.,com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
security: property package.definition value com.sun.javaws,com.sun.deploy,com.sun.jnlp
security: property package.definition new value com.sun.javaws,com.sun.deploy,com.sun.jnlp,org.mozilla.jss
basic: Added progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@cdfc9c
network: Cache entry found [url: http://localhost/Test/TestApplet/TestApplet.class, version: null]
network: Connecting http://localhost/Test/TestApplet/TestApplet.class with proxy=DIRECT
network: Connecting http://localhost:80/ with proxy=DIRECT
network: ResponseCode for http://localhost/Test/TestApplet/TestApplet.class : 304
network: Encoding for http://localhost/Test/TestApplet/TestApplet.class : null
network: Disconnect connection to http://localhost/Test/TestApplet/TestApplet.class
basic: Applet loaded.
basic: Applet resized and added to parent container
basic: PERF: AppletExecutionRunnable - applet.init() BEGIN ; jvmLaunch dt 263414 us, pluginInit dt 373873 us, TotalTime: 637287 us
basic: Applet initialized
basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@cdfc9c
basic: Applet made visible
basic: Starting applet
basic: Applet started
basic: Told clients applet is started
network: Cache entry found [url: http://localhost/Test/TestApplet/Listner_Class.class, version: null]
network: Connecting http://localhost/Test/TestApplet/Listner_Class.class with proxy=DIRECT
network: ResponseCode for http://localhost/Test/TestApplet/Listner_Class.class : 304
network: Encoding for http://localhost/Test/TestApplet/Listner_Class.class : null
network: Disconnect connection to http://localhost/Test/TestApplet/Listner_Class.class
Exception in thread "Thread-9" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:4463 accept,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkAccept(Unknown Source)
      at java.net.ServerSocket.implAccept(Unknown Source)
      at java.net.ServerSocket.accept(Unknown Source)
      at TestApplet.Listner_Class.Listener_Loop(Listner_Class.java:107)
      at TestApplet.Listner_Class.run(Listner_Class.java:65)
>>

Is there anything else I need to change or check?

Many Thanks
Mick BarryJava Developer
Top Expert 2010

Commented:
load it using http://192.168.0.79/, instead of localhost

Author

Commented:
I've just checked out test HTML page that we've been using(http://192.168.0.79/TNTctiTest/TNTctiTest.html) and in the section where the applet is embedded - it was sert to the following:-

>>
<applet code="tntcctapplet/TNTcti.class" width=0 height=0 codebase="http://localhost/TNTctiTest" style="height: 0px" id="tntctiapp">
>>

which I guess would explain why the applet uses localhost - Should I remove the codebase tag from the tag or chnage it to something else?

Thanks
Mick BarryJava Developer
Top Expert 2010

Commented:
change it to use 192....

Author

Commented:
I've chanaged the HTML to use 192.168.0.79 as follows:-

>>
<applet code="Test/TestApplet.class" width=0 height=0 codebase="http://192.168.0.79/Test" style="height: 0px" id="tntctiapp">
>>


but this still gives an access denied error. As a test, in the default permissions in teh java.policy file I've set

>>
permission java.net.SocketPermission "localhost:1024-", "listen, accept, connect, resolve";
>>

just to check that the applet still works when full permissions are granted. and from the testing, the applet works just fine with the socket funcitonality.

However, when I try to insert

>>
grant codeBase "http://192.168.0.79/" {
  permission java.net.SocketPermission "localhost:1024-", "listen, accept, connect, resolve";
};
>>
(after setting the default socket permission to "listen" only) I get the following

>>
basic: Applet initialized
basic: Removed progress listener: sun.plugin.util.GrayBoxPainter$GrayBoxProgressListener@133796
basic: Applet made visible
basic: Starting applet
basic: Applet started
basic: Told clients applet is started
network: Cache entry found [url: http://192.168.0.79/Test/TestApplet/Listner_Class.class, version: null]
network: Connecting http://192.168.0.79/Test/TestApplet/Listner_Class.class with proxy=DIRECT
network: ResponseCode for http://192.168.0.79/Test/TestApplet/Listner_Class.class : 304
network: Encoding for http://192.168.0.79/Test/TestApplet/Listner_Class.class : null
network: Disconnect connection to http://192.168.0.79/Test/TestApplet/Listner_Class.class
Exception in thread "Thread-9" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1261 accept,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkAccept(Unknown Source)
      at java.net.ServerSocket.implAccept(Unknown Source)
      at java.net.ServerSocket.accept(Unknown Source)
      at TestApplet.Listner_Class.Listener_Loop(Listner_Class.java:114)
      at TestApplet.Listner_Class.run(Listner_Class.java:73)
>>

It seems like the codebase definition is not picked up and it just uses the default....

Thanks.
Top Expert 2016

Commented:
>>
grant codeBase "http://192.168.0.79/" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, resolve";
};
>>

Make that (and others similar):
grant codeBase "http://192.168.0.79/-" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "accept, connect, resolve";
};

Open in new window

Author

Commented:
I've just modified the java.policy file but I still get the following error

>>
Exception in thread "Thread-9" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:2284 accept,resolve)
>> 

Any other ideas?

Thanks

// Standard extensions get all permissions by default

grant codeBase "file:${{java.ext.dirs}}/*" {
	permission java.security.AllPermission;
};


grant codeBase "http://192.168.0.79/-" { 
  permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve"; 
};


// default permissions granted to all domains

grant { 
	// Allows any thread to stop itself using the java.lang.Thread.stop()
	// method that takes no argument.
	// Note that this permission is granted by default only to remain
	// backwards compatible.
	// It is strongly recommended that you either remove this permission
	// from this policy file or further restrict it to code sources
	// that you specify, because Thread.stop() is potentially unsafe.
	// See "http://java.sun.com/notes" for more information.
	permission java.lang.RuntimePermission "stopThread";

	// allows anyone to listen on un-privileged ports
	permission java.net.SocketPermission "localhost:1024-", "listen";


	// "standard" properies that can be read by anyone

	permission java.util.PropertyPermission "java.version", "read";
	permission java.util.PropertyPermission "java.vendor", "read";
	permission java.util.PropertyPermission "java.vendor.url", "read";
	permission java.util.PropertyPermission "java.class.version", "read";
	permission java.util.PropertyPermission "os.name", "read";
	permission java.util.PropertyPermission "os.version", "read";
	permission java.util.PropertyPermission "os.arch", "read";
	permission java.util.PropertyPermission "file.separator", "read";
	permission java.util.PropertyPermission "path.separator", "read";
	permission java.util.PropertyPermission "line.separator", "read";

	permission java.util.PropertyPermission "java.specification.version", "read";
	permission java.util.PropertyPermission "java.specification.vendor", "read";
	permission java.util.PropertyPermission "java.specification.name", "read";

	permission java.util.PropertyPermission "java.vm.specification.version", "read";
	permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
	permission java.util.PropertyPermission "java.vm.specification.name", "read";
	permission java.util.PropertyPermission "java.vm.version", "read";
	permission java.util.PropertyPermission "java.vm.vendor", "read";
	permission java.util.PropertyPermission "java.vm.name", "read";
};

Open in new window

Top Expert 2016

Commented:
>>
grant codeBase "file:${{java.ext.dirs}}/*" {
        permission java.security.AllPermission;
};
>>

should be

grant codeBase "file:${java.ext.dirs}/-" {
        permission java.security.AllPermission;
};

Author

Commented:
Hi CEHJ

I updated the specific Java Policy as illustrated below:

>>

grant codeBase "file:${{java.ext.dirs}}/-" {
      permission java.security.AllPermission;
};


grant codeBase "http://192.168.0.79/-" {
  permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
};

>>

When I retested the Applet to ensure the Port was has been opened i.e. firing a test message  - The following Error still occurred regarding permissions:-

>>

Exception in thread "Thread-6" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1383 accept,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkAccept(Unknown Source)
      at java.net.ServerSocket.implAccept(Unknown Source)
      at java.net.ServerSocket.accept(Unknown Source)
>>

Is there any other ideas....
Mick BarryJava Developer
Top Expert 2010

Commented:
no, those changes won't make any difference
Mick BarryJava Developer
Top Expert 2010

Commented:
I suggest you stop tinkering with the policy file and start from scratch
Run it with an empty policy file when it needs access add a rule as required.
Top Expert 2016

Commented:
Make sure that you don't have the policy file open when it's getting accessed and check the last access time of the file

Author

Commented:
OK - I've reverted the Java.Policy back to default as illustrated below: -

>>
// Standard extensions get all permissions by default

grant codeBase "file:${{java.ext.dirs}}/*" {
      permission java.security.AllPermission;
};

// default permissions granted to all domains

grant {
      // Allows any thread to stop itself using the java.lang.Thread.stop()
      // method that takes no argument.
      // Note that this permission is granted by default only to remain
      // backwards compatible.
      // It is strongly recommended that you either remove this permission
      // from this policy file or further restrict it to code sources
      // that you specify, because Thread.stop() is potentially unsafe.
      // See "http://java.sun.com/notes" for more information.
      permission java.lang.RuntimePermission "stopThread";

      // allows anyone to listen on un-privileged ports
      permission java.net.SocketPermission "localhost:1024-", "listen";

      // "standard" properies that can be read by anyone

      permission java.util.PropertyPermission "java.version", "read";
      permission java.util.PropertyPermission "java.vendor", "read";
      permission java.util.PropertyPermission "java.vendor.url", "read";
      permission java.util.PropertyPermission "java.class.version", "read";
      permission java.util.PropertyPermission "os.name", "read";
      permission java.util.PropertyPermission "os.version", "read";
      permission java.util.PropertyPermission "os.arch", "read";
      permission java.util.PropertyPermission "file.separator", "read";
      permission java.util.PropertyPermission "path.separator", "read";
      permission java.util.PropertyPermission "line.separator", "read";

      permission java.util.PropertyPermission "java.specification.version", "read";
      permission java.util.PropertyPermission "java.specification.vendor", "read";
      permission java.util.PropertyPermission "java.specification.name", "read";

      permission java.util.PropertyPermission "java.vm.specification.version", "read";
      permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
      permission java.util.PropertyPermission "java.vm.specification.name", "read";
      permission java.util.PropertyPermission "java.vm.version", "read";
      permission java.util.PropertyPermission "java.vm.vendor", "read";
      permission java.util.PropertyPermission "java.vm.name", "read";
};
>>

By default all Sockets have permissions to Listen.... The Applet starts up as expected and a Socket is created to Listen on 1035.

When I try to fire a message to Port 1035 I will receive the following Permissions Issue from the JVM......

>>
Exception in thread "Thread-12" java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1350 accept,resolve)
      at java.security.AccessControlContext.checkPermission(Unknown Source)
      at java.security.AccessController.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkPermission(Unknown Source)
      at java.lang.SecurityManager.checkAccept(Unknown Source)
      at java.net.ServerSocket.implAccept(Unknown Source)
      at java.net.ServerSocket.accept(Unknown Source)
>> 

And also the Java Policy file was closed during the above testing....

Mick BarryJava Developer
Top Expert 2010

Commented:
> By default all Sockets have permissions to Listen.... The Applet starts up as expected and a Socket is created to Listen on 1035.

they shouldn't. Check that you don't have another policy file involved, eg.in your home directory
Mick BarryJava Developer
Top Expert 2010

Commented:
sorry, take that back didn't notice you had added that
Java Developer
Top Expert 2010
Commented:
ok, what happens when you add accept and resolve.

      permission java.net.SocketPermission "localhost:1024-", "listen, accept, resolve";

Author

Commented:
Hi,

I've updated the Java.Policy file with the following information as advised to include: "listen, accept, resolve" - with the updated policy I can now successfully fire a test message to Port 1035...

The next test is the Applet to fire a Socket message on Port 1034 but the receive the following permission error is displayed: -

>>
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1034 connect,resolve
>>
Top Expert 2016

Commented:
Please post as an attachment each current policy file

Author

Commented:
Updated Java.Policy file to - "listen, accept, resolve" - illustrated below:

>>
grant codeBase "file:${java.ext.dirs}/-" {
        permission java.security.AllPermission;
};

grant {
      // Allows any thread to stop itself using the java.lang.Thread.stop()
      // method that takes no argument.
      // Note that this permission is granted by default only to remain
      // backwards compatible.
      // It is strongly recommended that you e sources
      // that you specify, because Thread.stop() is potentiaeither remove this permission
      // from this policy file or further restrict it to codlly unsafe.
      // See "http://java.sun.com/notes" for more information.
      permission java.lang.RuntimePermission "stopThread";

      // allows anyone to listen on un-privileged ports
 
      permission java.net.SocketPermission "localhost:1024-", "listen, accept, resolve";
 
      permission java.util.PropertyPermission "java.version", "read";
      permission java.util.PropertyPermission "java.vendor", "read";
      permission java.util.PropertyPermission "java.vendor.url", "read";
      permission java.util.PropertyPermission "java.class.version", "read";
      permission java.util.PropertyPermission "os.name", "read";
      permission java.util.PropertyPermission "os.version", "read";
      permission java.util.PropertyPermission "os.arch", "read";
      permission java.util.PropertyPermission "file.separator", "read";
      permission java.util.PropertyPermission "path.separator", "read";
      permission java.util.PropertyPermission "line.separator", "read";

      permission java.util.PropertyPermission "java.specification.version", "read";
      permission java.util.PropertyPermission "java.specification.vendor", "read";
      permission java.util.PropertyPermission "java.specification.name", "read";

      permission java.util.PropertyPermission "java.vm.specification.version", "read";
      permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
      permission java.util.PropertyPermission "java.vm.specification.name", "read";
      permission java.util.PropertyPermission "java.vm.version", "read";
      permission java.util.PropertyPermission "java.vm.vendor", "read";
      permission java.util.PropertyPermission "java.vm.name", "read";
};
>>

Top Expert 2016

Commented:
Add the following as well
permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, resolve"; 

Open in new window

Author

Commented:
Hi updated the Java.Policy to include

>>
permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, resolve";
>>

Illustrated below is the revised Java.Policy File
>>
grant codeBase "file:${java.ext.dirs}/*" {
        permission java.security.AllPermission;
};

grant {
      // Allows any thread to stop itself using the java.lang.Thread.stop()
      // method that takes no argument.
      // Note that this permission is granted by default only to remain
      // backwards compatible.
      // It is strongly recommended that you e sources
      // that you specify, because Thread.stop() is potentiaeither remove this permission
      // from this policy file or further restrict it to codlly unsafe.
      // See "http://java.sun.com/notes" for more information.
      permission java.lang.RuntimePermission "stopThread";

      // allows anyone to listen on un-privileged ports
      permission java.net.SocketPermission "localhost:1024-", "listen, accept, resolve";  
      permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, resolve";
 
      permission java.util.PropertyPermission "java.version", "read";
      permission java.util.PropertyPermission "java.vendor", "read";
      permission java.util.PropertyPermission "java.vendor.url", "read";
      permission java.util.PropertyPermission "java.class.version", "read";
      permission java.util.PropertyPermission "os.name", "read";
      permission java.util.PropertyPermission "os.version", "read";
      permission java.util.PropertyPermission "os.arch", "read";
      permission java.util.PropertyPermission "file.separator", "read";
      permission java.util.PropertyPermission "path.separator", "read";
      permission java.util.PropertyPermission "line.separator", "read";

      permission java.util.PropertyPermission "java.specification.version", "read";
      permission java.util.PropertyPermission "java.specification.vendor", "read";
      permission java.util.PropertyPermission "java.specification.name", "read";

      permission java.util.PropertyPermission "java.vm.specification.version", "read";
      permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
      permission java.util.PropertyPermission "java.vm.specification.name", "read";
      permission java.util.PropertyPermission "java.vm.version", "read";
      permission java.util.PropertyPermission "java.vm.vendor", "read";
      permission java.util.PropertyPermission "java.vm.name", "read";
};
>>

The error is still persistent when the Applet try's to create a Port 1034 to send a message as illustrated below:

>>
java.security.AccessControlException: access denied (java.net.SocketPermission 127.0.0.1:1034 connect,resolve
>>
Top Expert 2016
Commented:
You need to add connect permission too

Author

Commented:
I've added connect to the Java Policy file as illustrated below:

>>
grant codeBase "file:${java.ext.dirs}/*" {
        permission java.security.AllPermission;
};

grant {
      // Allows any thread to stop itself using the java.lang.Thread.stop()
      // method that takes no argument.
      // Note that this permission is granted by default only to remain
      // backwards compatible.
      // It is strongly recommended that you e sources
      // that you specify, because Thread.stop() is potentiaeither remove this permission
      // from this policy file or further restrict it to codlly unsafe.
      // See "http://java.sun.com/notes" for more information.
      permission java.lang.RuntimePermission "stopThread";

      // allows anyone to listen on un-privileged ports
      permission java.net.SocketPermission "localhost:1024-", "listen, accept, connect, resolve";  
      permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
 
      permission java.util.PropertyPermission "java.version", "read";
      permission java.util.PropertyPermission "java.vendor", "read";
      permission java.util.PropertyPermission "java.vendor.url", "read";
      permission java.util.PropertyPermission "java.class.version", "read";
      permission java.util.PropertyPermission "os.name", "read";
      permission java.util.PropertyPermission "os.version", "read";
      permission java.util.PropertyPermission "os.arch", "read";
      permission java.util.PropertyPermission "file.separator", "read";
      permission java.util.PropertyPermission "path.separator", "read";
      permission java.util.PropertyPermission "line.separator", "read";

      permission java.util.PropertyPermission "java.specification.version", "read";
      permission java.util.PropertyPermission "java.specification.vendor", "read";
      permission java.util.PropertyPermission "java.specification.name", "read";

      permission java.util.PropertyPermission "java.vm.specification.version", "read";
      permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
      permission java.util.PropertyPermission "java.vm.specification.name", "read";
      permission java.util.PropertyPermission "java.vm.version", "read";
      permission java.util.PropertyPermission "java.vm.vendor", "read";
      permission java.util.PropertyPermission "java.vm.name", "read";
};

>>

The Applet can now Listen on Port 1035 and receive messages. Also Create a Port on 1034 to send messages without any Java Permission issue...
Top Expert 2016

Commented:
OK - so fixed then?

Author

Commented:
As previously stated we are concerned of the security risks of enabling all permissions from 1024 - 65535.

>>
  permission java.net.SocketPermission "localhost:1024-", "listen, accept, connect, resolve";
  permission java.net.SocketPermission "127.0.0.1:1024-", "listen, accept, connect, resolve";
>>

Would the client with the updated Java Policy be more at risk from malicious attacks from the internet...
Top Expert 2016

Commented:
Well you've now reverted to an earlier policy file, so you need to reinstate the codeBase restrictions i first recommended

Author

Commented:
Prompt assistance and knowledgeable support.
Mick BarryJava Developer
Top Expert 2010

Commented:
Thanks :)

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial