> I should clarify something. My objections mostly relate to the insistent > language in the SIP requiring Solr to have a substitute for the JSM. I'm > not quite against doing something but I might vote -0 on something that > seems to have a poor security payoff relative to the maintenance burden. > The more off-the-shelf, the better IMO. > Thank you for investing your time researching some options.
The security landscape has dramatically changed during the years that we have enjoyed JSM protection for Solr. It's a crazy world out there and every single code flaw, existing and future, will be found and exploited or published by so called security researchers. That's why I believe we need a centralized solution. >> Rejected Alternatives >> >> - *Staying on Java < 24* — not viable long-term; Solr must support >> current Java LTS releases. >> - *Removing JSM protections without any replacement* — unacceptable >> security regression. >> > Both Eric Pugh and I have challenged this. >> >> - *OS-level hardening only (systemd, seccomp)* — not cross-platform; >> does not cover Windows or macOS. >> > I challenge this. Why should the Solr project burden itself with building > & maintaining security mechanisms already provided by off-the-shelf tools? > If a user/operator wishes to run on Windows/macOS that may not have this > protection mechanism, it is a risk consideration for that user to consider, > but isn't a deal-breaker. The JSM wasn't/isn't a front-line defense; it's > a defense-in-depth strategy. Put differently, the protections here are > "best effort" but not worthy of a CVE if they were to falter. I want to > get Arnout's opinion on this supposition. Java Security Manager is a beast, but its file system read/write controls have saved us many a CVE in 9.x when JSM have been on by default. The SIP primarily focuses on sandboxing Solr for wrt file and network access. The security landscape has changed dramatically last few years, and solving file- and network restrictions in a central place through interception rathen than at each of the 100+ call sites is a more sustainable way. Users are free to add layers outside the JVM as well, such as systemd, container, SELinux etc. But be honest - how many small/medium organizations really do this? >> - *Dynamic ZK-watcher-based network policy* — correct but >> significantly more complex; adds ZK client dependency to the agent JAR. >> Superseded by port-based wildcards for intra-cluster traffic. >> - *Building a Java agent from scratch* — higher effort with no >> functional advantage over adapting the Apache 2.0-licensed OpenSearch >> implementation. >> >> I agree with not burdening this project with building & maintainining such > a mechanism. > > I'm not sure, to what degree, we can leverage that existing agent you speak > of without further burdening us. It's a burden/reward trade-off. If the agent becomes a true maintenance burden (i.e. a larger burden than handling the CVEs it would prevent, then a valid action is to remove the agent again. Like any other feature we develop and maintain. Good this is that this is pure Java, and production-ready stable code. > In your updated proposal, you point > out org.apache.solr.core.CoreContainer#assertPathAllowed That is called by > a number of places... although I *think* the original intention was only to > limit where cores are created? Can you elaborate on what the role of that > method *should* be and how the JSM might also or work? The pathAllowed checks (also the ones pre-dating the centralization in CoreContainer, were introduced in 8.x, before JSM was introduced or enabled by default. Initially assertPathAllowed would validate end-user API input to avoid cores being created or loaded outside blessed folders. It has then been re-used for other code locations that may do file access based on user-input in API or config. It as also extended to block UNC paths after many attacks with this as a vector. I believe perhaps pathAllowed would not have been written had JSM already been enforced. Although I don't know if you can block UNC with JSM? The SIP does not propose to remove pathAllowed now. One benefit of early detection is that we can give better context-sensitive error- and log messages rather than throwing an exception. The agent approach laid out sandboxes four attack vectors * File access outside a limited set of folders and full block of Windows UNC * Network access other than peer solr nodes and zk nodes * Disabllow calling System.exit() (mainly useful for 3rd party plugins?) * Disallow spawning processes A nice thing with the agent approach is that it is unintrusive and easy to disable, so users who want to take care of all this on OS level may disable it, and if we or users don't find value in it down the road they can disable it or we can remove it. Jan --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
