Re: Fwd: new hurdle for applications which programatically install a SecurityManager
Thanks for the quick response and for the pointer to https://bugs.openjdk.java.net/browse/JDK-8203316 The change in the default value of java.security.manager prevents Derby from installing a SecurityManager when the user forgets to. This increases Derby's attack surface, significantly in my opinion. On 11/18/21 11:21 AM, Sean Mullan wrote: On 11/18/21 1:22 PM, Rick Hillegas wrote: Here's the output I get when I run that program against 18-ea+23-1525 WITHOUT setting java.security.manager on the boot command line: Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release at java.base/java.lang.System.setSecurityManager(System.java:411) at DERBY_7126_B.main(DERBY_7126_B.java:34) Here's the output I get when I run that program against 18-ea+23-1525 but do set java.security.manager on the boot command line: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by DERBY_7126_B (file:/Users/rhillegas/src/) WARNING: Please consider reporting this to the maintainers of DERBY_7126_B WARNING: System::setSecurityManager will be removed in a future release Is this asymmetry in the handling of this new system property deliberate? Yes. The system property is read early (and never again) in VM init phase 3. If so, what is the motivation for this asymmetry? One of the motivations is to improve the performance of applications that do not use the Security Manager. These applications ideally should not have to incur the cost of supporting a SecurityManager if it is not used. By reading the system property early, the code for loading and checking the security field can be removed. More details are in the CSR for this change that initially went into JDK 12: https://bugs.openjdk.java.net/browse/JDK-8203316 If not, can the new property be made to operate like the other SecurityManager properties, that is, can the JDK be amended so that java.security.manager can be set programatically? AFAIK, the "java.security.manager" system property has always been read early before the main application is launched. Also, a change like that would negate the performance benefits described above. --Sean
Re: Fwd: new hurdle for applications which programatically install a SecurityManager
On 11/18/21 1:22 PM, Rick Hillegas wrote: Here's the output I get when I run that program against 18-ea+23-1525 WITHOUT setting java.security.manager on the boot command line: Exception in thread "main" java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release at java.base/java.lang.System.setSecurityManager(System.java:411) at DERBY_7126_B.main(DERBY_7126_B.java:34) Here's the output I get when I run that program against 18-ea+23-1525 but do set java.security.manager on the boot command line: WARNING: A terminally deprecated method in java.lang.System has been called WARNING: System::setSecurityManager has been called by DERBY_7126_B (file:/Users/rhillegas/src/) WARNING: Please consider reporting this to the maintainers of DERBY_7126_B WARNING: System::setSecurityManager will be removed in a future release Is this asymmetry in the handling of this new system property deliberate? Yes. The system property is read early (and never again) in VM init phase 3. If so, what is the motivation for this asymmetry? One of the motivations is to improve the performance of applications that do not use the Security Manager. These applications ideally should not have to incur the cost of supporting a SecurityManager if it is not used. By reading the system property early, the code for loading and checking the security field can be removed. More details are in the CSR for this change that initially went into JDK 12: https://bugs.openjdk.java.net/browse/JDK-8203316 If not, can the new property be made to operate like the other SecurityManager properties, that is, can the JDK be amended so that java.security.manager can be set programatically? AFAIK, the "java.security.manager" system property has always been read early before the main application is launched. Also, a change like that would negate the performance benefits described above. --Sean
Fwd: new hurdle for applications which programatically install a SecurityManager
Re-sending from the account linked to my security-dev subscription
Forwarded Message
Build 18-ea+23-1525 has introduced another hurdle for applications which
use the SecurityManager. In order to install a SecurityManager, you now
have to set -Djava.security.manager=allow on the boot command line. This
property cannot be set programatically, unlike the other system
properties related to the SecurityManager. I have attached a simple
repro of this asymmetry (DERBY_7126_B) to
https://issues.apache.org/jira/browse/DERBY-7126. The repro
programatically sets java.security.manager. Here's the code:
import java.io.PrintWriter;
import java.util.Properties;
/**
* Demonstrate that the SecurityManager can be installed by setting
*/
@SuppressWarnings("removal")
public class DERBY_7126_B
{
private static final String PROPERTY_FILE_NAME =
"/tmp/derby-7126_B.properties";
private static final String SECURITY_POLICY_FILE_NAME =
"/tmp/derby-7126_B.policy";
private static final String SECURITY_POLICY_FILE_URL = "file:" +
SECURITY_POLICY_FILE_NAME;
private final static String POLICY_FILE_PROPERTY =
"java.security.policy";
private static final String SECURITY_FILE_CONTENTS =
"grant\n" +
"{\n" +
" permission java.io.FilePermission \"/tmp/-\",
\"read,write,delete\";\n" +
"};\n"
;
public static void main(String... args) throws Exception
{
// write the policy file
try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
{ pw.write(SECURITY_FILE_CONTENTS); }
// start up a security manager using the policy file we just wrote
System.setProperty( POLICY_FILE_PROPERTY,
SECURITY_POLICY_FILE_URL );
System.setProperty( "java.security.manager", "allow" );
System.setSecurityManager( new SecurityManager() );
}
}
Here's the output I get when I run that program against 18-ea+23-1525
WITHOUT setting java.security.manager on the boot command line:
Exception in thread "main" java.lang.UnsupportedOperationException: The
Security Manager is deprecated and will be removed in a future release
at java.base/java.lang.System.setSecurityManager(System.java:411)
at DERBY_7126_B.main(DERBY_7126_B.java:34)
Here's the output I get when I run that program against 18-ea+23-1525
but do set java.security.manager on the boot command line:
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by DERBY_7126_B
(file:/Users/rhillegas/src/)
WARNING: Please consider reporting this to the maintainers of DERBY_7126_B
WARNING: System::setSecurityManager will be removed in a future release
Is this asymmetry in the handling of this new system property
deliberate? If so, what is the motivation for this asymmetry? If not,
can the new property be made to operate like the other SecurityManager
properties, that is, can the JDK be amended so that
java.security.manager can be set programatically?
Thanks,
-Rick
new hurdle for applications which programatically install a SecurityManager
Build 18-ea+23-1525 has introduced another hurdle for applications which
use the SecurityManager. In order to install a SecurityManager, you now
have to set -Djava.security.manager=allow on the boot command line. This
property cannot be set programatically, unlike the other system
properties related to the SecurityManager. I have attached a simple
repro of this asymmetry (DERBY_7126_B) to
https://issues.apache.org/jira/browse/DERBY-7126. The repro
programatically sets java.security.manager. Here's the code:
import java.io.PrintWriter;
import java.util.Properties;
/**
* Demonstrate that the SecurityManager can be installed by setting
*/
@SuppressWarnings("removal")
public class DERBY_7126_B
{
private static final String PROPERTY_FILE_NAME =
"/tmp/derby-7126_B.properties";
private static final String SECURITY_POLICY_FILE_NAME =
"/tmp/derby-7126_B.policy";
private static final String SECURITY_POLICY_FILE_URL = "file:" +
SECURITY_POLICY_FILE_NAME;
private final static String POLICY_FILE_PROPERTY =
"java.security.policy";
private static final String SECURITY_FILE_CONTENTS =
"grant\n" +
"{\n" +
" permission java.io.FilePermission \"/tmp/-\",
\"read,write,delete\";\n" +
"};\n"
;
public static void main(String... args) throws Exception
{
// write the policy file
try (PrintWriter pw = new PrintWriter(SECURITY_POLICY_FILE_NAME))
{ pw.write(SECURITY_FILE_CONTENTS); }
// start up a security manager using the policy file we just wrote
System.setProperty( POLICY_FILE_PROPERTY,
SECURITY_POLICY_FILE_URL );
System.setProperty( "java.security.manager", "allow" );
System.setSecurityManager( new SecurityManager() );
}
}
Here's the output I get when I run that program against 18-ea+23-1525
WITHOUT setting java.security.manager on the boot command line:
Exception in thread "main" java.lang.UnsupportedOperationException: The
Security Manager is deprecated and will be removed in a future release
at java.base/java.lang.System.setSecurityManager(System.java:411)
at DERBY_7126_B.main(DERBY_7126_B.java:34)
Here's the output I get when I run that program against 18-ea+23-1525
but do set java.security.manager on the boot command line:
WARNING: A terminally deprecated method in java.lang.System has been called
WARNING: System::setSecurityManager has been called by DERBY_7126_B
(file:/Users/rhillegas/src/)
WARNING: Please consider reporting this to the maintainers of DERBY_7126_B
WARNING: System::setSecurityManager will be removed in a future release
Is this asymmetry in the handling of this new system property
deliberate? If so, what is the motivation for this asymmetry? If not,
can the new property be made to operate like the other SecurityManager
properties, that is, can the JDK be amended so that
java.security.manager can be set programatically?
Thanks,
-Rick
