Perhaps Solr should come up with a basic auth wrapper requiring a randomly
generated token from the logs as a password printed at the very end of
startup messages. This of course needs to show up in zookeeper too so that
inter-node requests work. Nice if the UI at some point handles it, but as a
temporary "until you set this up" type of feature, letting the browser
throw up a 401 based login seems fine. This of course could be disabled
either by a configuration in security.json or a system property named
something like no.security.at.all
>From a first tutorial perspective requests via the admin ui (or direct
browser url) only get asked once per session, and sending a basic auth
header is a very normal thing in curl. (and people who don't like typing
don't use curl anyway). Things like Postman also handle this smoothly.
Additionally it might be good to add a header to query responses something
like:
"insecure": [
"This cluster is running without https, communications with and among
this cluster are easily spied upon by third parties. Configuring https
removes this message",
"This cluster is running with default log token basic auth. Anyone with
access to the logs can gain full control of Solr. Configuring security.json
with an authentication plugin removes this message"
"This cluster is running such that every user is a super-user and can
create/delete/update all collections and any data or configuration.
Configuring an authorization plugin in security.json removes this message"
]
possibly also messages about zookeeper acls, or whatever else we think is
important.
All such messages should be removable via properties like:
"no.security.advice.all", "no.security.advice.https",
"no.security.advice.authn", "no.security.advice.authz" etc. for backwards
compatibility and dev/testing of course.
This should ensure that the users (or at least one user in the
organization) will be aware of their own insecure practices.
-Gus
On Fri, May 7, 2021 at 3:53 PM David Smiley <dsmi...@apache.org> wrote:
> > I would like to be able to define core specific permissions with
> rule-based
> > authorization in security.json in the same way you can do for
> collections.
>
> PRs/Patches welcome... but I think you're going to have to accept migrating
> to SolrCloud. SolrCloud has gotten better year over year.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, May 7, 2021 at 3:39 AM Thomas Corthals <tho...@klascement.net>
> wrote:
>
> > I would like to be able to define core specific permissions with
> rule-based
> > authorization in security.json in the same way you can do for
> collections.
> >
> > Thomas
> >
> > Op do 6 mei 2021 om 23:25 schreef David Smiley <dsmi...@apache.org>:
> >
> > > I'm reaching out to our user community to get opinions on what Solr
> > should
> > > do to be more secure-by-default.
> > >
> > > TL;DR: Solr 9 has better secure-by-defaults, but maybe we should do
> more
> > > like have Solr pick some of it's default settings dependent on a new
> > > env=dev|prod.
> > >
> > > I was shown a glimpse of a massive list of Solr servers exposed on the
> > > public internet by a security researcher. I'm kinda blown away that so
> > > many people would be so careless. I think Solr could and should run
> with
> > > better "secure-by-default" settings.
> > >
> > > The situation will be much better in Solr 9 -- and I'll give a
> shout-out
> > of
> > > thanks to Rob Muir for helping make this so. Here's a couple prominent
> > > ones:
> > > * Solr's Jetty now binds to localhost by default, configurable via
> > > SOLR_JETTY_HOST. Before 9, you can configure a similar thing in the
> > Jetty
> > > config files. SOLR-13985
> > > * Java's SecurityManager sandbox is enabled by default. -- SOLR-13984.
> > > This option also exists in Solr since 8.5, toggle-able
> > > via SOLR_SECURITY_MANAGER_ENABLED. Mostly this prevents the worst of
> > > security bugs -- RCE.
> > >
> > > I wonder if users will promptly set SOLR_JETTY_HOST=0.0.0.0 to get
> > anything
> > > done? I think so... but it's something, protecting some users.
> > >
> > > Perhaps Solr ought to default to requiring a username/password? I've
> > heard
> > > this suggestion and it's an obvious one even if some of us (me
> included)
> > > worry that it would make it too annoying to play with Solr when getting
> > > started. I think the concerns could be mitigated based on the
> approach.
> > > If Solr had an opt-in env=dev setting, for example, then Solr could not
> > > insist on authentication, whereas a default env=prod would insist. Of
> > > course the authentication or lack thereof could be explicitly
> configured
> > or
> > > disabled at the user's prerogative. What I like about an "env" setting
> > is
> > > that many other settings could be gated on this as well.
> > >
> > > I particularly like the idea of an env=dev|prod setting because a
> variety
> > > of settings in Solr could have a default that is dependent on this
> value.
> > > In particular I argue that a env=prod should result in Solr's config
> APIs
> > > being disabled -- equivalent to -Ddisable.configEdit=true. I believe a
> > > minority of Solr users actually use these APIs, yet they are
> frequently a
> > > step in exploiting weaknesses in Solr.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> >
>
--
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)
