[ https://issues.apache.org/jira/browse/SOLR-13991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987112#comment-16987112 ]
ASF subversion and git services commented on SOLR-13991: -------------------------------------------------------- Commit aebf7f7a463329879123b6436dd711e62d3f6d37 in lucene-solr's branch refs/heads/gradle-master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aebf7f7 ] SOLR-13991: clean up permissions in solr-tests.policy AKA break all the tests to hell, please ping the issue for repeated test failures > 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 > Priority: Major > Fix For: 8.4 > > Attachments: SOLR-13991.patch, SOLR-13991.patch, SOLR-13991.patch, > SOLR-13991.patch > > > 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org