Hi, Welcoming more feedback on this approach.
I'm planning to move to implementation phase on Wednesday, to get a first version of the agent ready for testing. But it would be helpful with as much feedback on the SIP high level design before I start implementing. Thanks David for your intial feedback. Jan > 1. mai 2026 kl. 14:30 skrev Gus Heck <[email protected]>: > > I know it's probably unrealistic because corporate environments into which > solr is deployed likely would have difficulty with it, but there is a JDK > fork that keeps and improves the Security Manager... It's supported by the > descendants of the Apache River project. > https://github.com/pfirmstone/DirtyChai > > Probably not useful, but perhaps interesting. Certainly we are not the only > ones irritated by the loss of the security manager. > > On Thu, Apr 30, 2026 at 4:08 AM Jan Høydahl <[email protected]> wrote: > >>> 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] >> >> > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
