jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fschumac...@apache.org
Subject svn commit: r1844855 - in /jmeter/trunk/xdocs: changes.xml usermanual/remote-test.xml
Date Thu, 25 Oct 2018 18:18:06 GMT
Author: fschumacher
Date: Thu Oct 25 18:18:05 2018
New Revision: 1844855

URL: http://svn.apache.org/viewvc?rev=1844855&view=rev
Log:
Add a short paragraph on how to use a security manager with JMeter.

Closes #406 on github

Modified:
    jmeter/trunk/xdocs/changes.xml
    jmeter/trunk/xdocs/usermanual/remote-test.xml

Modified: jmeter/trunk/xdocs/changes.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1844855&r1=1844854&r2=1844855&view=diff
==============================================================================
--- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
+++ jmeter/trunk/xdocs/changes.xml [utf-8] Thu Oct 25 18:18:05 2018
@@ -124,6 +124,7 @@ Summary
     <li><bug>62821</bug><pr>405</pr>Use SHA-512 checksums instead
of MD5 to verify jar downloads</li>
     <li><pr>408</pr>Log an informational message instead of an stack trace,
when JavaFX is not found for the <code>RenderInBrowser</code> component.</li>
     <li><pr>412</pr>Update Chinese translation. Contributed by 刘士 (liushilive
at outlook.com).</li>
+    <li><pr>406</pr>Add a short paragraph on how to use a security manager
with JMeter.</li>
 </ul>
 
  <!-- =================== Bug fixes =================== -->

Modified: jmeter/trunk/xdocs/usermanual/remote-test.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/remote-test.xml?rev=1844855&r1=1844854&r2=1844855&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/remote-test.xml (original)
+++ jmeter/trunk/xdocs/usermanual/remote-test.xml Thu Oct 25 18:18:05 2018
@@ -360,6 +360,93 @@ This is not really a problem as there is
   </p>
 </subsection>
 
+<subsection name="&sect-num;.7 Using a security-manager" anchor="security-manager">
+  <p>When running JMeter in a distributed environment you have to be aware, that JMeter
is basically a remote execution agent on both the server and client side. This could be used
by a malicious party to gain further access, once it has compromised one of the JMeter clients
or servers. To mitigate this Java has the concept of a security manager that gets asked by
the JVM before potential dangerous actions are executed. Those actions could be resolving
host names, creating or reading files or executing commands in the OS.</p>
+  <p>The security manager can be enabled by setting the Java system properties <code>java.security.manager</code>
and <code>java.security.policy</code>. Be sure to have a look at the <a href="https://docs.oracle.com/javase/tutorial/security/tour2/index.html">Quick
Tour of Controlling Applications</a>.</p>
+  <p>Using the new mechansism of <code>setenv.sh</code> (or <code>setenv.bat</code>
under Windows) you can enable the security manager by adding the following code snippet to
<code>${JMETER_HOME}/bin/setenv.sh</code>:</p>
+  <source>JVM_ARGS=" \
+   -Djava.security.manager \
+   -Djava.security.policy=${JMETER_HOME}/bin/java.policy \
+   -Djmeter.home=${JMETER_HOME} \
+"</source>
+  <p>The JVM will now add the policies defined in the file <code>${JMETER_HOME}/bin/java.policy</code>
to the possibly globally defined policies. If you want your definition to be the only source
for policies, use two equal signs instead of one when setting the property <code>java.security.policy</code>.</p>
+  <p>The policies will be dependent upon your use case and it might take a while to
find the correct restricted and allowed actions. Java can help you find the needed policies
with the property <code>java.security.debug</code>. Set it to <code>access</code>
and it will log all permissions, that it gets asked to allow. Simply add the following line
to your <code>setenv.sh</code>:</p>
+  <source>JVM_ARGS="${JVM_ARGS} -Djava.security.debug=access"</source>
+  <p>It might look a bit strange, that we define a Java system property <code>jmeter.home</code>
with the value of <code>${JMETER_HOME}</code>. This variable will be used in the
example <code>java.policy</code> to limit the file system access and allow it
only to read JMeters configuration and libraries and restrict write access to specific locations,
only.</p>
+  <p>The following policy definition file has been used for a simple remote test. You
will probably have to tweak the policies, when you run more complex scenarios. The test plans
are somewhere placed inside the users home directory under a directory called <code>jmeter-testplans</code>.
The sample <code>java.policy</code> looks like:</p>
+  <source>
+grant codeBase "file:${jmeter.home}/bin/*" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/jorphan.jar" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/log4j-api-2.11.0.jar" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/log4j-slf4j-impl-2.11.0.jar" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/slf4j-api-1.7.25.jar" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/log4j-core-2.11.0.jar" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/ext/*" {
+  permission java.security.AllPermission;
+};
+
+grant codeBase "file:${jmeter.home}/lib/httpclient-4.5.6.jar" {
+  permission java.net.SocketPermission "*", "connect,resolve";
+};
+
+grant codeBase "file:${jmeter.home}/lib/darcula.jar" {
+  permission java.lang.RuntimePermission "modifyThreadGroup";
+};
+
+grant codeBase "file:${jmeter.home}/lib/xercesImpl-2.12.0.jar" {
+  permission java.io.FilePermission "${java.home}/lib/xerces.properties", "read";
+};
+
+grant codeBase "file:${jmeter.home}/lib/groovy-all-2.4.15.jar" {
+  permission groovy.security.GroovyCodeSourcePermission "/groovy/script";
+  permission java.lang.RuntimePermission "accessClassInPackage.sun.reflect";
+  permission java.lang.RuntimePermission "getProtectionDomain";
+};
+
+grant {
+  permission java.io.FilePermission "${jmeter.home}/backups", "read,write";
+  permission java.io.FilePermission "${jmeter.home}/backups/*", "read,write,delete";
+  permission java.io.FilePermission "${jmeter.home}/bin/upgrade.properties", "read";
+  permission java.io.FilePermission "${jmeter.home}/lib/ext/-", "read";
+  permission java.io.FilePermission "${jmeter.home}/lib/ext", "read";
+  permission java.io.FilePermission "${jmeter.home}/lib/-", "read";
+  permission java.io.FilePermission "${user.home}/jmeter-testplans/-", "read,write";
+  permission java.io.SerializablePermission "enableSubclassImplementation";
+  permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
+  permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.dynalink.support";
+  permission java.lang.RuntimePermission "accessClassInPackage.sun.awt";
+  permission java.lang.RuntimePermission "accessClassInPackage.sun.misc";
+  permission java.lang.RuntimePermission "accessClassInPackage.sun.swing";
+  permission java.lang.RuntimePermission "accessDeclaredMembers";
+  permission java.lang.RuntimePermission "createClassLoader";
+  permission java.lang.RuntimePermission "createSecurityManager";
+  permission java.lang.RuntimePermission "getClassLoader";
+  permission java.lang.RuntimePermission "getenv.*";
+  permission java.lang.RuntimePermission "nashorn.createGlobal";
+  permission java.util.PropertyPermission "*", "read";
+};
+  </source>
+  <note>The usage of <code>java.security.AllPermission</code> is an easy
way to make your test plans work, but it might be a dangerous shortcut on your path to security.</note>
+</subsection>
+
 </section>
 
 </body>



Mime
View raw message