In [1], we have discussed how to fix security violations when Java Security Manager is enabled at WebLogic Server start-up. In this article, we will look at how to troubleshoot security policy-related issues by using the java.security.debug option.
To troubleshoot security policy-related issues, you can configure Java Security Manager with the level of security-related information to be reported using:
Setting "policy" option will allow Security Manager to report the details of
Beside of policy loading entries, you could also find other entries (e.g. permission granting entries) such as:
Enabling access option, allows Security Manager to print all results from the AccessController.checkPermission method.
java.security.debug
To troubleshoot security policy-related issues, you can configure Java Security Manager with the level of security-related information to be reported using:
java.security.debugTo find out what the debug option offers, do:
java -Djava.security.debug=helpIf using JDK 7, you can find more information from [2]. As for JDK 8, we have included the list of debugging options in the Addendum for your convenience. Note that you need to separate multiple options with a comma. For example, we will look at the output from the following combination of debug options:
-Djava.security.debug=policy,access
policy Option
Setting "policy" option will allow Security Manager to report the details of
Loading and granting permissions with policy fileFor example, from the WebLogic Server log file, you can find the following entries:
policy: Adding policy entry: policy: signedBy null policy: codeBase file:/home/myusername/wls1221141208/wlserver/server/lib/- policy: ("java.security.AllPermission" "" " ") policy: policy: Adding policy entry: policy: signedBy null policy: codeBase file:/home/myusername/wls1221141208/wlserver/modules/- policy: ("java.security.AllPermission" " " " ") policy:
which correspond to grant entries from the weblogic.policy:[5]
grant codeBase "file:/home/myusername/wls1221141208/wlserver/server/lib/-" { permission java.security.AllPermission; }; grant codeBase "file:/home/myusername/wls1221141208/wlserver/modules/-" { permission java.security.AllPermission; };
Beside of policy loading entries, you could also find other entries (e.g. permission granting entries) such as:
policy: granting ("java.util.PropertyPermission" "java.version" "read") policy: granting ("java.util.PropertyPermission" "java.vendor" "read")
access Option
Enabling access option, allows Security Manager to print all results from the AccessController.checkPermission method.
You can use the following options with the access option:
- stack: Include stack trace
- domain: Dump all domains (i.e., protection domain) in context
- failure:[3] Before throwing exception, dump stack and domain that do not have permission
- permission=<classname>[4]
- Only dump output if specified permission is being checked
- codebase=<URL>
- This option would be useful when customer desires to trace the permissions impact of only the code in a given code souce, such as jar file.
- URL is the location of the specified code base.
- Note that because the comma (',") is used as multi options separator, if the URL contains comma, the security debugger would not work properly as expected, it is recommended that the URL should not include character comma (','), semicolon (';'), and space.
Addendum
$ jdk-hs/bin/java -Djava.security.debug=help all turn on all debugging access print all checkPermission results certpath PKIX CertPathBuilder and CertPathValidator debugging combiner SubjectDomainCombiner debugging gssloginconfig GSS LoginConfigImpl debugging configfile JAAS ConfigFile loading configparser JAAS ConfigFile parsing jar jar verification logincontext login context results jca JCA engine class debugging policy loading and granting provider security provider debugging pkcs11 PKCS11 session manager debugging pkcs11keystore PKCS11 KeyStore debugging sunpkcs11 SunPKCS11 provider debugging scl permissions SecureClassLoader assigns ts timestamping The following can be used with access: stack include stack trace domain dump all domains in context failure before throwing exception, dump stack and domain that didn't have permission The following can be used with stack and domain: permission=only dump output if specified permission is being checked codebase= only dump output if specified codebase is being checked The following can be used with provider: engine= only dump output for the specified list of JCA engines. Supported values: Cipher, KeyAgreement, KeyGenerator, KeyPairGenerator, KeyStore, Mac, MessageDigest, SecureRandom, Signature.
References
- Java Security Manager: java.security.AccessControlException: access denied (Xml and More)
- Troubshooting Security
- Debugging Security Policy Issues
- JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
- Fine granularity diagnosis on security
- -Djava.security.debug=access,stack,permission=java.io.FilePermission
- Java SecurityManager: "java.security" and "java.policy" Files (Xml and More)
Thank you for sharing this wonderful resource! It's crucial for raising awareness. For further information, don't forget to read this article Color Blind Test. Teachers can better support impacted pupils by using color-blind examinations.
ReplyDelete