[
https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987204#comment-16987204
]
Robert Muir commented on SOLR-13993:
------------------------------------
Yeah, we have the general solr sandbox, which would stop what you have in the
test. We cleaned up permissions so that {{System.setSecurityManager(null);}}
won't work anymore, but its probably just a few more lines to maybe accomplish
the same thing with reflection (e.g. setAccessible) or some other dangerous
permission that is granted to solr code.
Also the current general solr sandbox can do other bad things, such read all
files on the system (since the permissions currently do not restrict that)
I was thinking for this issue to wrap the whole response "write" method with
something like
https://docs.oracle.com/javase/8/docs/api/java/security/AccessController.html#doPrivileged-java.security.PrivilegedExceptionAction-java.security.AccessControlContext-java.security.Permission...-
{quote}
with a privilege scope limited by specified Permission arguments
{quote}
In other words, we'd wrap velocity write method with this, so it runs with a
smaller list of permissions than everything that is piled in solr... "special
sandbox". Ideally this list would be empty, not sure what it needs to keep
working :)
> 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
>
>
> 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: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
