Robert Muir created SOLR-13994:
----------------------------------
Summary: OS-level sandboxing to prevent RCE
Key: SOLR-13994
URL: https://issues.apache.org/jira/browse/SOLR-13994
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Robert Muir
The "correct" way to secure solr app is just to follow the guidelines java
provides: https://www.oracle.com/technetwork/java/seccodeguide-139067.html
But we can cheat if we need to. Every popular OS has a "one-way" function to
turn off execution, so no crazy exploit can work around it (unless they have
e.g. kernel exploit).
There are serious tradeoffs for solr: e.g. no way to "pass through" stuff like
hadoop's crappy stuff, and stuff like java's {{-XX:OnOutOfMemoryError=}} cant
work. But you can be pretty fucking confident RCE won't happen :)
I have implemented such stuff before, for example:
https://github.com/elastic/elasticsearch/blob/f48ddd53fd66cfef3032a17023cd9e2f88702af9/server/src/main/java/org/elasticsearch/bootstrap/SystemCallFilter.java
Personally, I would prefer we not do this stuff. It is better to secure the
code "cleanly" and not resort to such native hacks. And I think its not a good
idea to invite a bunch of native code and the crazy bugs it can bring, this is
a java project!
But if circumstances demand, maybe we need the crutch, even temporarily. So I'm
opening the issue anyway, because it is a nuclear option we can apply. And code
I have done before is under AL2.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
