lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Jira)" <>
Subject [jira] [Commented] (SOLR-13993) sandbox velocity template render
Date Tue, 03 Dec 2019 19:22:00 GMT


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

with a privilege scope limited by specified Permission arguments

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

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

View raw message