[
https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988401#comment-16988401
]
Robert Muir commented on SOLR-13993:
------------------------------------
I'll make a followup JIRA for reducing permissions further. I think this is
actually where we should start. Its already got 'security code' which sucks,
but that's the price of having scripting engine features, thats what you sign
up for since you are allowing untrusted code execution :) And don't want to
blame velocity, i found two other places in solr at least that need the same
thing.
Rather than restrict the FS read here with more complicated security code, I
think its a bigger win to fix it for the whole solr: SOLR-14015
The sandbox here will prevent all kinds of nonsense that otherwise the regular
solr policy would allow. its more than just preventing process execution, it
prevents me from e.g. using java's network apis to portscan and pivot to other
machines in your backend infrastructure, prevents me from writing anywhere to
the filesystem at all (e.g. overwriting some solr startup script and mucking
with sensitive settings or other stuff that lets me go further), and so on. use
your imagination.
> sandbox velocity template render
> --------------------------------
>
> Key: SOLR-13993
> URL: https://issues.apache.org/jira/browse/SOLR-13993
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Robert Muir
> Priority: Major
> Attachments: SOLR-13993.patch, SOLR-13993.patch, SOLR-13993.patch
>
>
> This thing seems dangerous :)
> Making the whole solr secure is a whole nother thing: (see e.g. SOLR-13991
> and we haven't even gotten started). Its pretty difficult to convert whole
> large app to work securely. It is going to take time.
> In the meantime, if we have things that might do something dangerous, and
> security manager is enabled, we can put them into a special little sandbox
> and throw away the key: for example we can intentionally discard permissions
> we don't need so they can't launch stuff, if we really don't trust them, we
> can start filtering what classes classloader will load.
> This isn't that crazy at all to do, e.g. your web browser does similar tricks
> to try to sandbox specific parts that might do something unexpected and cause
> security issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
