Re: [VOTE] Release Solr 9.2.1 RC1
I failed to convince the PMC about the severity of the exploits that I was hoping to address in the blocker issues. I don't have time nor patience to pursue those blockers any more. I withdraw my vote (-1) on this release. On Mon, 1 May 2023 at 02:42, Jan Høydahl wrote: > > Without polluting this thread, I'll just say that this assertion is > wrong. > > If you can demonstrate how someone with full API access, but no write > > access to disk or ZK, can execute any user code, I'll stand corrected. > > Hi Noble/Ishan. I regret using the phrasing "arbitrary plugin code upload" > about the config APIs. It was not precise. > > I was trying to paraphrase the definition of the "config-edit" permission > from memory, but obviosly did a poor job :) > Let me instead quote the ref-guide for "config-edit" permission: > https://solr.apache.org/guide/solr/9_2/deployment-guide/rule-based-authorization-plugin.html > > > config-edit:... Because configs can add libraries/custom code from > various locations, loading any new code via a trusted SolrConfig is > explicitly allowed for users with this permission... > > I.e. currently remote streaming can (by design) be enabled by users with > config-edit and systems without auth/z. > Let's move any further discussion to relevant JIRAs and/or other threads > and leave this for voting. > > Jan > > > 30. apr. 2023 kl. 03:20 skrev Ishan Chattopadhyaya < > ichattopadhy...@gmail.com>: > > > >> it is by design to allow full access, even arbitrary plugin code upload, > > by users with config-edit permission and in unprotected Solr instances. > > > > Without polluting this thread, I'll just say that this assertion is > wrong. > > If you can demonstrate how someone with full API access, but no write > > access to disk or ZK, can execute any user code, I'll stand corrected. > > > > I'll write a more detailed reply in a different thread on the measures we > > have taken to prevent that, let alone allow full access "by design". > > > > On Sun, 30 Apr, 2023, 6:32 am Noble Paul, wrote: > > > >> On Sun, Apr 30, 2023, 10:09 AM Jan Høydahl > wrote: > >> > >>> I maintain my +1 vote, as it is by design to allow full access, even > >>> arbitrary plugin code upload, by > >> > >> > >> There is no such "design" as you say Jan. Show me a single feature that > can > >> upload and run code without file system or direct zk access > >> > >> users with config-edit permission and in unprotected Solr instances. > >>> I do support discussing new defaults to some of these setting, but that > >>> can happen in the open for a future release, no rush as this is by > >>> definition not a bug or vulnerability. > >>> > >>> Jan > >>> > 29. apr. 2023 kl. 17:54 skrev Justin Sweeney < > >> justin.sweene...@gmail.com > : > > I'm going to proceed with this release as is, we can follow up with an > additional release as needed. Voting will close 2023-04-30 at 15:00 > >> UTC. > > On Sat, Apr 29, 2023 at 10:37 AM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > > > https://issues.apache.org/jira/browse/SOLR-16777 is fixed. I've > added > >>> it > > to > > the release branch. > > The other one will require me some more time, maybe another day. > > Justin, I believe a re-spin is warranted to accommodate this, but I > >>> leave > > it to your judgement. > > > > On Sat, 29 Apr 2023 at 12:07, Ishan Chattopadhyaya < > > ichattopadhy...@gmail.com> wrote: > > > >> In my opinion, these two are blockers. > >> > >> https://issues.apache.org/jira/browse/SOLR-16776 > >> https://issues.apache.org/jira/browse/SOLR-16777 > >> > >> In case we decide not to respin to accommodate these, these should > be > >> carried over to a 9.2.2 release. > >> > >> On Sat, 29 Apr, 2023, 7:54 am Ishan Chattopadhyaya, < > >> ichattopadhy...@gmail.com> wrote: > >> > >>> (FYI, -1 on a release is not a veto. Just a simple vote.) > >>> > >>> On Sat, 29 Apr, 2023, 6:53 am Ishan Chattopadhyaya, < > >>> ichattopadhy...@gmail.com> wrote: > >>> > Sure, carry on with this release. > > I vote -1 on this release, and I'll prepare for a follow on > release > after this one is done. > > On Sat, 29 Apr, 2023, 2:45 am David Smiley, > > wrote: > > > I'm going to challenge Ishan and say that there is no change > >> coming > > that > > warrants halting a bugfix/patch release, as the proposed change > >> that > > Ishan > > speaks of is an "improvement" that helps security and is not a > > bug/vulnerability being fixed. It would also bring a backwards > > compatibility change. So please do continue with this long > >> delayed > > bugfix > > release! > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > >
Re: [Proposal] Security Working Group
Pretty sleepy thread so far; apparently nobody else is interested in talking about Solr security -- LOL ;-) ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Apr 26, 2023 at 8:25 AM Gus Heck wrote: > Thanks David. It would be great to have you if you can find time for it. As > far as time commitment goes, I think it should become minimal after a while > unless we have a flood of security reports to respond to. For a little > while after initial organization, I think the members will want to put a > bit of effort into hitting some of the goals I mentioned. > > On Tue, Apr 25, 2023 at 12:28 AM David Smiley wrote: > > > This is a thoughtful organization attempt and needed, I think. Thanks > Gus! > > > > I want to see if I could get a security specialist/engineer where I work > to > > help us with this. I'm tempted to say I'm joining this thing but I'm > weary > > of dedicating time per week. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Mon, Apr 24, 2023 at 1:33 PM Gus Heck wrote: > > > > > *Rationale* > > > > > > Over the course of the last decade the way software security is viewed > > has > > > changed. Solr has changed significantly over this time too and we have > > > gained some important security features and fixed a variety of > > > vulnerabilities. However, I think as a project we have not really > > developed > > > a clear vision of what our security goals and use cases are. I have > > > witnessed a fair bit of variability in the responses to security > related > > > queries, and I think much of the variability comes from conflation > among > > > "good practical advice", "somewhat dated advice" and "varying notions > of > > > supported use cases". We also regularly receive reports to the > > > secur...@solr.apache.org address that involve investigations into > > systems > > > that are not properly secured to begin with or configured to explicitly > > > allow the dangerous behavior and it's a shame to see security > researchers > > > waste their time on that. Finally, the PMC and set of people subscribed > > to > > > secur...@solr.apache.org is a large enough group that incoming mails > > often > > > seem to languish in a classic example of nobody having actual specific > > > responsibility for responding. > > > > > > *Proposal* > > > The Solr PMC should appoint from among its members either 3 to 5 > > > individuals to serve as a "security working group" Membership in the > > > "Security Working Group" requires subscribing to > > secur...@solr.apache.org, > > > and a 30 minute conference call once or twice a month. This working > group > > > would have the following goals. > > > > > >1. Establish a relationship with someone who's core job function is > > >computer security, rather than providing search (I'm hoping the ASF > > has > > >some people who secure their systems that could be a resource). This > > > person > > >should be willing to offer a systems security perspective on our > goals > > > and > > >the security functionality we provide. > > >2. Develop a clear statement of the security use cases we would like > > to > > >support, and exposition of some scenarios that are clearly out of > > scope. > > >This results in a proposal to be discussed on the dev list and users > > > list > > >and eventually voted on. > > >3. Identification of use cases we would like to support that are not > > yet > > >supported, and publicize them to encourage these contributions. > > >4. Review of documentation to ensure consistency with our current > > state > > >(security only, perhaps annually?). > > >5. Creation of a "security report checklist" that security > researchers > > >can self apply before they submit reports. > > >6. Form letters for consistent response to reports that haven't > passed > > >the checklist. > > >7. Provide consistent and prompt responses to possible > > >vulnerabilities reported to secur...@apache.org. Those subscribed > to > > >secur...@solr.apache.org who are not in the working group should > > allow > > >the working group time to respond before responding themselves. > > >8. When asked, offer opinions on proposed new security features > > >regarding consistency with the goals (working group to discuss, > return > > > with > > >an opinion, always publically and just as a voice in the > conversation, > > > not > > >as any sort of veto/control, decisions are still up to the list of > > > course). > > > > > > NON-GOAL: The group is not responsible for fixing security bugs or > adding > > > security features. (nothing stopping them of course, just not the point > > of > > > the group, which is a goal setting and consistency oriented group) > > > > > > *Volunteer* > > > > > > And to lower the barrier to things started, I volunteer to participate > in > > >
Re: [VOTE] Release Solr 9.2.1 RC1
> Without polluting this thread, I'll just say that this assertion is wrong. > If you can demonstrate how someone with full API access, but no write > access to disk or ZK, can execute any user code, I'll stand corrected. Hi Noble/Ishan. I regret using the phrasing "arbitrary plugin code upload" about the config APIs. It was not precise. I was trying to paraphrase the definition of the "config-edit" permission from memory, but obviosly did a poor job :) Let me instead quote the ref-guide for "config-edit" permission: https://solr.apache.org/guide/solr/9_2/deployment-guide/rule-based-authorization-plugin.html > config-edit:... Because configs can add libraries/custom code from various > locations, loading any new code via a trusted SolrConfig is explicitly > allowed for users with this permission... I.e. currently remote streaming can (by design) be enabled by users with config-edit and systems without auth/z. Let's move any further discussion to relevant JIRAs and/or other threads and leave this for voting. Jan > 30. apr. 2023 kl. 03:20 skrev Ishan Chattopadhyaya > : > >> it is by design to allow full access, even arbitrary plugin code upload, > by users with config-edit permission and in unprotected Solr instances. > > Without polluting this thread, I'll just say that this assertion is wrong. > If you can demonstrate how someone with full API access, but no write > access to disk or ZK, can execute any user code, I'll stand corrected. > > I'll write a more detailed reply in a different thread on the measures we > have taken to prevent that, let alone allow full access "by design". > > On Sun, 30 Apr, 2023, 6:32 am Noble Paul, wrote: > >> On Sun, Apr 30, 2023, 10:09 AM Jan Høydahl wrote: >> >>> I maintain my +1 vote, as it is by design to allow full access, even >>> arbitrary plugin code upload, by >> >> >> There is no such "design" as you say Jan. Show me a single feature that can >> upload and run code without file system or direct zk access >> >> users with config-edit permission and in unprotected Solr instances. >>> I do support discussing new defaults to some of these setting, but that >>> can happen in the open for a future release, no rush as this is by >>> definition not a bug or vulnerability. >>> >>> Jan >>> 29. apr. 2023 kl. 17:54 skrev Justin Sweeney < >> justin.sweene...@gmail.com : I'm going to proceed with this release as is, we can follow up with an additional release as needed. Voting will close 2023-04-30 at 15:00 >> UTC. On Sat, Apr 29, 2023 at 10:37 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > https://issues.apache.org/jira/browse/SOLR-16777 is fixed. I've added >>> it > to > the release branch. > The other one will require me some more time, maybe another day. > Justin, I believe a re-spin is warranted to accommodate this, but I >>> leave > it to your judgement. > > On Sat, 29 Apr 2023 at 12:07, Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> In my opinion, these two are blockers. >> >> https://issues.apache.org/jira/browse/SOLR-16776 >> https://issues.apache.org/jira/browse/SOLR-16777 >> >> In case we decide not to respin to accommodate these, these should be >> carried over to a 9.2.2 release. >> >> On Sat, 29 Apr, 2023, 7:54 am Ishan Chattopadhyaya, < >> ichattopadhy...@gmail.com> wrote: >> >>> (FYI, -1 on a release is not a veto. Just a simple vote.) >>> >>> On Sat, 29 Apr, 2023, 6:53 am Ishan Chattopadhyaya, < >>> ichattopadhy...@gmail.com> wrote: >>> Sure, carry on with this release. I vote -1 on this release, and I'll prepare for a follow on release after this one is done. On Sat, 29 Apr, 2023, 2:45 am David Smiley, > wrote: > I'm going to challenge Ishan and say that there is no change >> coming > that > warrants halting a bugfix/patch release, as the proposed change >> that > Ishan > speaks of is an "improvement" that helps security and is not a > bug/vulnerability being fixed. It would also bring a backwards > compatibility change. So please do continue with this long >> delayed > bugfix > release! > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Fri, Apr 28, 2023 at 3:28 PM Justin Sweeney < > justin.sweene...@gmail.com> > wrote: > >> It sounds like the general consensus from the thread regarding >> the > issue >> was that while some changes to make that less risky are >> worthwhile, > they >> are not blockers for the release. Did that change? >> >> I just hate to hold up the release any longer unless we have a >>> truly
