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)
