Robert Muir created SOLR-13991:
----------------------------------
Summary: clean up permissions in solr-tests.policy
Key: SOLR-13991
URL: https://issues.apache.org/jira/browse/SOLR-13991
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Robert Muir
The solr-tests.policy is currently way too lenient. Its useful for tests but
pretty worthless at defending against any attacker "for real"
For example imagine i can execute arbitrary java-ish code:
{code}
Runtime.getRuntime().exec("id");
{code}
With a security manager enabled, I'd get an exception like this:
java.security.AccessControlException: access denied ("java.io.FilePermission"
"<<ALL FILES>>" "execute")
Because the current policy is so lenient and has wildcard RuntimePermission,
the next thing i'd try (disable security manager, then launch process) would
happily execute:
{code}
System.setSecurityManager(null);Runtime.getRuntime().exec("id");
{code}
That's because the current wildcard permission allows
{{RuntimePermission("setSecurityManager")}}.
There are other variants I could use, some explained by java's docs:
https://docs.oracle.com/javase/7/docs/api/java/lang/RuntimePermission.html
It will take time and pain to clean up this stuff: e.g. fixing code and maybe
even third-party dependencies, but gotta start somewhere. I think splitting up
the wildcards is a good first step :)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
