We Keep Coding

In openjdk, security policies are not taking effect

In redhat-openjdk:1.8.0, jvm java.policy and custom.policy file's java.version is being effective on the activeprocess
I've configured the java process to use java security manager and it uses Apache server to run the process. So Apache client look for "java.version" read permission in default and/or custom policy file.
I've included ready property permission, yet i'm getting weird AccessControlException.
Exception i'm seeing is:
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read")
I've right permissions in place Property permission entry in jvm/secruity/java.policy
permission java.util.PropertyPermission "java.version", "read";
and in custom.policy ( -Djava.security.manager -Djava.security.policy=custom.policy), file path fully-qualified, i just shortened for better understanding):
permission java.util.PropertyPermission "java.version", "read";
Expectation is to run java process with out issues, but that's not happening.
Edit 1:
I've also tried enforcing all permission using below line:
grant{
permission java.security.AllPermission;
};
But seems like it is still not working. I've also tried using '==' while setting up policy file, which mean
`If you use
java -Djava.security.manager -Djava.security.policy==someURL SomeApp
(note the double equals) then just the specified policy file will be used; all the ones indicated in the security properties file will be ignored.`
As per jdk 8 doc
Any help is much appreciated.

Looks to me that the policy is not in effect. In case you have multiple JDK releases installed, are you sure that you've modified the default policy for the same release that you are running with? I'd start by granting AllPermissions just to make sure that the policy is in effect, and then focus on the permission line itself.

ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")

When starting for example Elasticsearch 5.5 :
main ERROR Could not register mbeans java.security.AccessControlException: access denied ("javax.management.MBeanTrustPermission" "register")

Workaround with Oracle Java 1.8.0_131 is to open file <jre>/lib/security/java.policy and add this line to grant section (i.e. between curly brackets):
permission javax.management.MBeanTrustPermission "register";
Why workaround? The upright solution would be to specify extra grant section which code exactly should get this permission.

got the same error and the answer is here java.security.AccessControlException when using Ant, but runs ok when invoking java from console
Append the grant section in java.policy file with
permission javax.management.MBeanTrustPermission "register";

I had this same issue when moving from a single instance to two instances locally.
I tried what Alice suggested above. Even re-installed Elasticsearch (5.5.0).
I also updated my Java to the latest one for Linux provided by Oracle.
Nothing was working. Then I discovered, that I couldn't just take the elasticsearch-5.5.0/config directory and rename it to elasticsearch-5.5.0/node1.
So... I had to leave that config directory in place and clone it to node1/node2.
EVEN if I configure path.config in the runtime args, ES still needs that base line config directory.
Hope this helps.

I faced same issue on Ubuntu-16.04 system.
Solution:
ElasticSeearch service is not allowed to run for "ROOT" user. That's why change the ownership of elasticsearch folder with below command:
go to Elasticseach installation directory
$ sudo chown -R user_name:user_Group elasticsearch-5.5.0
$/bin/elasticsearch
this will start elasticsearch service. It is working form me perfectly.

Tomcat AccessControlException despite using AllPermission

I'm attempting to deploy a WAR to Tomcat and running into problems with the Java Security Manager. This is Tomcat 7.0.55 running Java 1.8.0, and Tomcat is started with parameters like this:
-Dcatalina.base="/path/to/apache-tomcat-7.0.55"
-Dcatalina.home="/path/to/apache-tomcat-7.0.55"
-Djava.endorsed.dirs="/path/to/apache-tomcat-7.0.55\endorsed"
-Djava.security.manager
-Djava.security.policy="/path/to/config/custom_catalina.policy"
The important thing here is that it's enabling the Java Security Manager and then pointing it at a custom security policy, which looks like this:
grant {
permission java.security.AllPermission;
};
It seems like this should result in the rather pointless configuration of activating the security manager and then telling it to just allow everything (I don't run the server so don't blame me!). However, when I deploy my WAR it fails with several stack traces containing things like:
Caused by: java.security.AccessControlException: access denied ("java.util.PropertyPermission" "java.version" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:457) ~[?:1.8.0_51]
at java.security.AccessController.checkPermission(AccessController.java:884) ~[?:1.8.0_51]
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) ~[?:1.8.0_51]
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1294) ~[?:1.8.0_51]
at java.lang.System.getProperty(System.java:753) ~[?:1.8.0_51]
at org.apache.commons.lang3.JavaVersion.maxVersion(JavaVersion.java:196) ~[commons-lang3-3.4.jar:3.4]
I've tried explicitly granting AllPermission to my own application with something like:
grant codeBase "file:${catalina.home}/webapps/myApp/-" {
permission java.security.AllPermission;
};
and even explicitly granting the PropertyPermission to read java.version. None of it makes any difference. The same AccessControlExceptions still get thrown and prevent deployment.
What is going on here? How can I troubleshoot this?

Ours was not coming during deployment, rather while heavy load testing.
We changed the Connector in server.xml from Nio2 to Nio and it solved problem for us
org.apache.coyote.http11.Http11NioProtocol (The first version of NIO, instead of NIO2).
We didn't disable tomcat security manager, that is against our firm's policy.

Rythm template engine with GAE/J: AccessControlException in even simplest case

I am trying to use the Rythm template engine on Google App Engine/Java devserver (GAE/J). This is a bare-bones install with nothing but Rythm added to the base GAE devserver.
The question Rythm template engine and GAE doesn't quite answer my question (the source code pointed to in the answer gives a 404 error).
Started by adding the following code to my servlet code:
response.getWriter().println(Rythm.render("Successfully logged in as: #who",
user.getNickname()));
and I get:
java.security.AccessControlException: access denied ("java.io.FilePermission" "/var/folders/91/nv5sbz412b188nk22m644mq80000gn/T/__rythm" "read")
I thought this is happening because the Rythm template engine tries to look in /var to see whether to treat first parameter to Rythm.render as a filename or not, and GAE throws the AccessControlException because you're not supposed to access the filesystem outside of the war.
I then added the following lines before the call to Rythm.render (these are essentially copy-and-pasted from Rythm's HelloWorld example):
// use Map to store the configuration
Map<String, Object> map = new HashMap<String, Object>();
// tell rythm where to find the template files
map.put("home.template", ".");
// init Rythm with our predefined configuration
Rythm.init(map);
Still get that same exception. Changing the "." to "/" as value for home.template gives:
access denied ("java.io.FilePermission" "/Successfully logged in as: #who" "read")
When I tried:
map.put("home.template", this.getServletContext().getRealPath("/"));
I still get the same exception. Why is Rythm looking at /var/folders/91/nv5sbz412b188nk22m644mq80000gn/T/__rythm at all? Stack trace is available at: https://drive.google.com/file/d/0B6dOUTDGuy2AWjR3Tmt2WTlkOUE/edit?usp=sharing (is there a better way to share a stack trace?)
Need help!
Here are the versions:
GAE: 1.8.7
Maven: 3.1.1
Rythm: 1.0-b11-SNAPSHOT
OS: OS X 10.9

You need to disable engine.file_write configuration to allow Rythm be working with GAE. Check more about the configuration on http://rythmengine.org/doc/configuration.md#engine_file_write_enabled

prohibit the call to System.exit

I'm trying to prohibit the call to System.exit(int); in some jars.
These jars will be developed by external teams and loaded by our "container" application .
My first reflex is to use the java security manager:
-Djava.security.manager-Djava.security.debug=all
with the simplest ${user.home}/.java.policy file :
grant {};
Although I can no longer call such as System.getProperties () (since I do not have java.util.PropertyPermission), I can do a System.exit (0) !!
The option java.security.debug=all gives the following console:
scl: getPerms ProtectionDomain (file: my-bin-path <no sign certificates>)
sun.misc.Launcher $ AppClassLoader # 10385c1
<no principals>
java.security.Permissions # 15b7986 (
(java.lang.RuntimePermission exitVM)
(java.io.FilePermission \my-bin-path\- read)
)
Why do all classes in my-bin-path have java.lang.RuntimePermission exitVM granted ?????
thanks

According to the bug report, http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4286238, the policy file wasn't dis-allowing System.exit() calls. I'm running an application with Java 1.6 and am still seeing this bug despite it being "resolved." Similar to the OP, I have a system wide policy file which does not include a permission for exitVM. However, I am able to exit the application without any exception being thrown.
My understanding of including a custom policy file is that all permissions are blacklisted except those included in the policy file. Since exitVM is not included it should be disallowed (overriding the default permission mentioned by MicSim). But this is not the case.

From the Javadoc of RuntimePermission:
Note: The "exitVM.*" permission is automatically granted to all code loaded from the application class path, thus enabling applications to terminate themselves.
Reading this, it seems you have to explicitly deny this permission by writing your own SecurityManager. (For an example, see this answer: Prevent System.exit to actually exit the JVM)

Alternatively you could do AOP and intercept System.exit. Doing that yourself would be: create your own class loader and use BPEL to trace System.exit, and patch those calls. Really not a large effort.