Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X
In the Tomcat Security Considerations it's recommended to start Tomcat with the Security Manager.
However, when I startup Tomcat with the security option I get an error containing 'java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "modifyThread")' when trying to read the platform-settings.json.
Are there any templates / best practices for how to configure the catalina.policy file with the ThingWorx webapp?
Solved! Go to Solution.
Hello @mneumann,
Cool, I thought that Security Managers died together with applets a decade ago
I think the biggest problem with your empirical fine-grain approach (without using wildcards) is that you'll never really know if you've already identified all issues or not yet (it's an NP-complete problem after all). This alone should prevent you from attempting it for any practical purposes.
I wonder if there's any business requirement behind this (Co-hosting ThingWorx with other webapps? Allowing users to load their own custom extensions?)
As for the settings related to filesystem access (the only reasonable SM use case really) I guess that simply restricting Tomcat user access on your *nix box is enough (and probably more reliable as well, given that Tomcat and/or JVM may contain their own bugs and vulnerabilities).
Regards,
Constantine
Hi Michael,
I did not tested it, but please check this link, where it is explained some configuration for Tomcat Security Manager.
You probably need to add a line " permission java.io.FilePermission "${thingworx.home}${file.separator}-", "read,write";" where thingworx.home will be an environment variable that has the path to the folder containing the platform-settings.json.
Hope it helps,
Raluca Edu
PS. Nice hearing from you!!!!
Hi Raluca!
Nice hearing from you as well
The link was quite helpful and I have found similar sites as well.
I managed to move on to various other errors. At the moment I'm stumbling from error into error with granting the permissions on a proper level. So far I've struggled up to the point where I defined these:
grant codeBase "file:${catalina.base}/webapps/Thingworx/-" {
permission java.io.FilePermission "/ThingworxPlatform/-", "read, write";
permission java.io.FilePermission "/ThingworxStorage/-", "read, write, delete";
permission java.io.FilePermission "/ThingworxBackupStorage/-", "read, write, delete";
permission java.io.FilePermission "/ThingworxSourceControl/-", "read, write, delete";
permission java.lang.RuntimePermission "getenv.THINGWORX_PLATFORM_SETTINGS";
permission java.lang.RuntimePermission "modifyThread";
permission java.util.PropertyPermission "com.fasterxml.jackson.core.util.BufferRecyclers.trackReusableBuffers", "read";
// This needs to be removed and replaced with proper permission management
// permission java.security.AllPermission;
};
I'm a bit concerned about having to go through hundreds of exceptions to get it running - while not being sure, if I captured all of the required permissions in the end. The good thing so far is, that Tomcat is nice enough to tell exactly which class / permission is missing.
I could just run the AllPermissions - but that would be the same like not having the SecurityManager at all.
Hello @mneumann,
Cool, I thought that Security Managers died together with applets a decade ago
I think the biggest problem with your empirical fine-grain approach (without using wildcards) is that you'll never really know if you've already identified all issues or not yet (it's an NP-complete problem after all). This alone should prevent you from attempting it for any practical purposes.
I wonder if there's any business requirement behind this (Co-hosting ThingWorx with other webapps? Allowing users to load their own custom extensions?)
As for the settings related to filesystem access (the only reasonable SM use case really) I guess that simply restricting Tomcat user access on your *nix box is enough (and probably more reliable as well, given that Tomcat and/or JVM may contain their own bugs and vulnerabilities).
Regards,
Constantine
Hi @Constantine
yeah, the Security Manager is still in the best practices for hardening Tomcat in their guides.
At the moment we are only using ThingWorx for Tomcat.
After trying to configure all the security exceptions I found in the quite obvious error messages, I got stuck at a point where the error message was not stating clearly what exact permission is required. I decided therefore to keep the SecurityManager, but just give the ThingWorx WebApp all permissions.
I agree that this step-by-step approach is kind of nonsense. Even if I managed to find all required permissions to run ThingWorx, I strongly suspect this does not cover all possible scenarios and ThingWorx would fail later at some critical point due to the missing permissions. I wouldn't want to risk that this will then later manifest in a Production Environment
Having the Security Manager enabled and granting all permissions to the ThingWorx WebApp is probably a good enough start. The rest is hardened on OS and process level anyway.
Thanks and Regards,
Michael