[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988639#comment-16988639 ] ASF subversion and git services commented on SOLR-13993: Commit e77027dd8c4b29b21d5343f31c860571864b48e5 in lucene-solr's branch refs/heads/gradle-master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e77027d ] SOLR-13993: sandbox velocity template render (if security manager is enabled) The solr permissions are weak sauce due to the huge number of features, third-party dependencies, etc. Hence they have access to do many things. For "scripting" such as velocity we have to look at a more aggressive stance: Step 1: Can we wrap a sandbox around the whole goddamn thing and call it a day? Step 2: Let's separate the "engine" from "untrusted code" and only be an asshole to the latter. Step 3: Java's security is shit, Lets contain that classloader and whitelist access. > 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 > Fix For: 8.4 > > Attachments: SOLR-13993.patch, 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988516#comment-16988516 ] ASF subversion and git services commented on SOLR-13993: Commit e6728cdf64472e91186b3cc080d2d1c5de774196 in lucene-solr's branch refs/heads/branch_8x from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e6728cd ] SOLR-13993: sandbox velocity template render (if security manager is enabled) The solr permissions are weak sauce due to the huge number of features, third-party dependencies, etc. Hence they have access to do many things. For "scripting" such as velocity we have to look at a more aggressive stance: Step 1: Can we wrap a sandbox around the whole goddamn thing and call it a day? Step 2: Let's separate the "engine" from "untrusted code" and only be an asshole to the latter. Step 3: Java's security is shit, Lets contain that classloader and whitelist access. > 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 > Fix For: 8.4 > > Attachments: SOLR-13993.patch, 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988501#comment-16988501 ] ASF subversion and git services commented on SOLR-13993: Commit e77027dd8c4b29b21d5343f31c860571864b48e5 in lucene-solr's branch refs/heads/master from Robert Muir [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e77027d ] SOLR-13993: sandbox velocity template render (if security manager is enabled) The solr permissions are weak sauce due to the huge number of features, third-party dependencies, etc. Hence they have access to do many things. For "scripting" such as velocity we have to look at a more aggressive stance: Step 1: Can we wrap a sandbox around the whole goddamn thing and call it a day? Step 2: Let's separate the "engine" from "untrusted code" and only be an asshole to the latter. Step 3: Java's security is shit, Lets contain that classloader and whitelist access. > 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, > 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
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987533#comment-16987533 ] Robert Muir commented on SOLR-13993: I think I can nuke the TODOs if we figure out how to plugin to velocity classloading mechanism (i think its resourceloader api), sorry i dont know it, i have to study their docs first. current patch doesn't try to do that, its just a brute approach: so there is no separation of "what the engine can do" vs "what the user template can do", hence bogus permissions we don't want. > 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: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987436#comment-16987436 ] Robert Muir commented on SOLR-13993: I attached a patch with a starter sandbox. I tweaked Erik's testcase (thank you) to be a little more benign, and test something that the rest of solr code can do, but velocity can't. The velocity stuff runs with a lot less privileges now than the rest of solr code. The main downside is that it still has read access to all files. I'm fairly certain it just needs access to the classpath, so that should really be refined. But classloaders are complicated, gotta start somewhere, and this is a hell of a lot less than what is in the solr policy file. > 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 > > > 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
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[
https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16987155#comment-16987155 ] Erik Hatcher commented on SOLR-13993: - Attached patch exercises the test security manager which does the trick (when run from `ant test`). Testing without the security manager (from IntelliJ) fails two of those tests appropriately. > 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
[jira] [Commented] (SOLR-13993) sandbox velocity template render
[ https://issues.apache.org/jira/browse/SOLR-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986607#comment-16986607 ] Robert Muir commented on SOLR-13993: looking in now. we can implement this as long as the tests pass. > 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 > > 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
