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 <gus.h...@gmail.com> 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 <dsmi...@apache.org> 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 <gus.h...@gmail.com> 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
> > > this WG for at least a year, and spend up to 2h/week on it. I don't
> think
> > > any members should be expected to dedicate more than that to it, and
> > > probably many weeks the time required should be less.
> > >
> > > *Feedback*
> > >
> > > Of course if you think this idea can be tweaked or improved, speak up!
> > The
> > > whole reason this is mailed to the dev list is to get broad feedback so
> > > that we can implement the best improvements possible.
> > >
> > > -Gus
> > >
> >
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Reply via email to