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

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

Basically i'm trying to ensure i dont break *any tests* including slow and 
nightly! Those definitely contribute to the pain level :)

I really believe the only way we can make progress here is via our tests. 
That's why I'm gonna try to make as many "test-only" changes as possible so we 
can minimize breakage.

At some point I hope we say, hey, let's put some securitymanager protection in 
"for real". But I think a test-first approach will be the safest way. For 
example, it lets idiot guys like me explore the state space and understand 
where the vulns lie without breaking any users. Though it may annoy devs 
(SORRY!)

> 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
>         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

Reply via email to