Hi, Opensearch has released v3.0 with their new java agent capable of filtering network and file access. They wrote a blog post about their thinking here https://opensearch.org/blog/finding-a-replacement-for-jsm-in-opensearch-3-0/ This is for information / food for thought. Please don't read it as a proposal for Solr to do exaclty the same. But do let it inform the SIP of what options we have.
Jan > 30. juni 2025 kl. 18:52 skrev David Smiley <dsmi...@apache.org>: > > I think Eric proposes _completely_ removing Solr's references to the > security manager (and thus not use it) in Solr main/10. Such a move > wouldn't block pursuing alternatives discussed in the SIP. > > On Thu, Jun 5, 2025 at 11:45 AM Houston Putman <hous...@apache.org> wrote: > >> Sorry for the late reply, been vacationing and busy! >> >> Thanks for getting this going Jan. This is a great SIP. >> >> I've put a good amount of thought into this, especially: >> >> >>> - Limit what file paths can be read/written >>> >>> >> And I don't think it's an easy thing to solve, but something we certainly >> need to care about. And hopefully this new solution will work better with >> the Solr system properties (comma separated list of paths), that the >> Security Manager couldn't do. >> >> - Houston >> >> On Thu, Jun 5, 2025 at 7:59 AM David Smiley <dsmi...@apache.org> wrote: >> >>>> I know you have under "Rejected Alternatives" the statement "Leaving >> Solr >>> unprotected", but honestly, I think that is just too broad of a >> statement. >>> >>> >>> I completely agree; that felt wrong when I read that. The >> SecurityManager >>> is not Solr's front-line protection mechanism -- that's authentication & >>> authorization plugins. The SM was always an auxiliary nice-to-have >>> secondary to that. It's also well within the user's power to add general >>> purpose mechanisms requiring no special enablement within Solr >> whatsoever: >>> such as mTLS via Istio. >>> >>> On Thu, Jun 5, 2025 at 7:17 AM David Eric Pugh <de...@yahoo.com.invalid> >>> wrote: >>> >>>> Ten is the perfect time to rip it out. Let's separate ripping it out >>>> from "whatever else we decide"... Otherwise we'll bike shed it to >> death! >>>> I know you have under "Rejected Alternatives" the statement "Leaving >> Solr >>>> unprotected", but honestly, I think that is just too broad of a >>> statement. >>>> >>>> >>>> Plus, I don't actually see why ideas like "Build a custom Java Agent" >> are >>>> really needed... I think we look at what the rest of the Java-world is >>>> doing and copy them. And if that is "they never adopted JSM and >>> therefore >>>> are not impacted" then let's do that. Let's NOT build a custom Java >>> Agent >>>> ;-). If there is a great maintained third party project that does >> great >>>> stuff we could leverage, like any other depenendency, then let's do >> that >>>> instead. And if there isn't anything, well, maybe we are just >> following >>>> the path of the Java-world.... >>>> >>>> >>>> On Wednesday, June 4, 2025 at 11:54:21 PM EDT, David Smiley < >>>> dsmi...@apache.org> wrote: >>>> >>>> Thanks for raising this topic and putting time into it. >>>> >>>> IMO the most useful thing to add is a test taming protection mechanism >>> that >>>> ensures that tests don't write to places in the project that should be >>>> read-only. Basically, if "git" would flag a change, then the test is >>>> at-fault. This was a fantastic benefit of the security manager. I've >>> made >>>> this mistake before and surely it happened before the SM was used in >> this >>>> way: you write a test that uses one of the Solr home templates, but not >>>> intending to actually write data there but it happens. The insidious >>> part >>>> is then another test comes along and reads data that shouldn't be >>> there. I >>>> started chatting with Gemini on a solution involving a Gradle plugin >> that >>>> would run "git status" before & after. I may explore that further. >> If I >>>> don't... ah well; whatever. Move on. >>>> >>>> I don't put much stock in the original / standard use of the >>>> SecurityManager. The burden of maintaining its configuration and >>>> trade-offs has been annoying. The very vast majority of the Java >>> developer >>>> world has ignored it, yet we embraced it. Shrug. If you haven't >>> noticed, >>>> there aren't a lot of developer/maintenance hours being put into Solr >>>> lately, so let's not overthink a replacement or if there needs to be >> one >>> in >>>> any way. 13 days later, you get the only reply (mine) -- case in >> point. >>>> Sorry for the sad dose of reality. >>>> >>>> ~ David >>>> >>>> On Thu, May 22, 2025 at 6:01 AM Jan Høydahl <jan....@cominvent.com> >>> wrote: >>>> >>>>> Hi, >>>>> >>>>> Let's kick off a discussion on what protections we'd want to put in >>> place >>>>> when Java Security Manager is gone in Java 24. >>>>> >>>>> Since this is a major topic likely spanning many parts of Solr, I >> made >>> a >>>>> SIP-24 for it: >>>>> >>>>> >>>>> >>>> >>> >> https://cwiki.apache.org/confluence/display/SOLR/SIP-24%3A+Java+Security+Manager+replacemen >>>>> >>>>> I do not intend to "lead" this effort, but hoping that kick-starting >>> this >>>>> discussion will lead to at least a set of JIRA issues being created >> for >>>>> concrete actions for the most important actions. >>>>> >>>>> Jan >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
