lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Jira)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-13991) clean up permissions in solr-tests.policy
Date Tue, 03 Dec 2019 01:55:00 GMT

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

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

[~ichattopadhyaya] if you can beast it, i would appreciate it. Of course i am most worried
about windows. The concern is around lots of hadoop conditional code... basically if (windows)
.... 

90% of the time if a test fails because of security reasons the SecurityException bubbles
up and its clear as day what needs to happen. But again, if there is some bad exception handling
(LOOKING AT YOU HADOOP) then, you'll need to dig to figure out why: https://issues.apache.org/jira/browse/SOLR-13991?focusedCommentId=16986324&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16986324

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


Mime
View raw message