lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Jira)" <>
Subject [jira] [Updated] (SOLR-13991) clean up permissions in solr-tests.policy
Date Mon, 02 Dec 2019 23:32:00 GMT


Robert Muir updated SOLR-13991:
    Attachment: SOLR-13991.patch

> clean up permissions in solr-tests.policy
> -----------------------------------------
>                 Key: SOLR-13991
>                 URL:
>             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:
> access denied ("" "<<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:
> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message