You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Robert Muir (Jira)" <ji...@apache.org> on 2019/12/02 20:07:00 UTC

[jira] [Commented] (SOLR-13991) clean up permissions in solr-tests.policy

    [ https://issues.apache.org/jira/browse/SOLR-13991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986324#comment-16986324 ] 

Robert Muir commented on SOLR-13991:
------------------------------------

This isn't anything more fun than running tests in a loop and debugging failures to narrow stuff down. Usually test fails clearly and its pretty fast to add what is needed to the policy. 

The only annoying ones are the hadoop related failures, sometimes exceptions get swallowed and you can't tell why it failed. When that happens, I debug it like this:
{noformat}
ant test -Dtestcase=HdfsThreadLeakTest -Dargs="-Djava.security.debug=access,failure"
{noformat}

Of course running all tests is slow so the iteration is painful. But I am working on it.

> 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
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org