insecure permissions set on /etc/opensearch/ directory?

[artificial-intelligence]

Hi,

there seems to be an error regarding the correct filesystem permissions for opensearch in conjunction with the opensearch security plugin, which runs by default when installing the opensearch provided deb package.

the code sets the bits, afaik here:

https://github.com/opensearch-project/OpenSearch/blob/611ecc2ad50c7e1833e7fe8ef2a6cabeb6028c57/distribution/packages/build.gradle#L216C15-L216C20

but opensearch security plugin, which runs by default in your debian based installs, btw, despite a comment in the code saying it should not be run in production (sic!), complains:

[2023-07-21T13:11:54,849][INFO ][o.o.s.OpenSearchSecurityPlugin] [controller3-LAB] Clustername: opensearch
[2023-07-21T13:11:54,857][WARN ][o.o.s.OpenSearchSecurityPlugin] [controller3-LAB] Directory /etc/opensearch has insecure file permissions (should be 0700)

see a bugreport we got in the openstack kolla-ansible deployment of opensearch:

https://bugs.launchpad.net/kolla-ansible/+bug/2028376

Logs:

https://paste.opendev.org/show/bC7trEauLd93b9osSQQi/

Permissions on the file system:

https://paste.opendev.org/show/b853xDI5mOLeKwRaGokf/

Am I missing something here?

Thanks for taking a look!

[dblock]

@davidlago help sort this out?

[davidlago]

@opensearch-project/engineering-effectiveness might be a good first stop to take a look as this has to do (it sounds like) with how we build and bundle.

despite a comment in the code saying it should not be run in production (sic!)

Which comment are you referring to and how are you running OpenSearch? Just want to make sure... the warnings we usually print out are when a cluster is run with the demo configuration (the ones with the demo certificates etc) as those are well known and thus offer not much in terms of security (see red box warning here)

[bbarani]

Adding @peterzhuamazon and @prudhvigodithi to this thread for further analysis.

[lukas-fichtner]

any updates on this?

[minalsha]

@bbarani , @peterzhuamazon , @prudhvigodithi can you please share your inputs from your assessment?

[artificial-intelligence]

@opensearch-project/engineering-effectiveness might be a good first stop to take a look as this has to do (it sounds like) with how we build and bundle.

despite a comment in the code saying it should not be run in production (sic!)

Which comment are you referring to and how are you running OpenSearch? Just want to make sure... the warnings we usually print out are when a cluster is run with the demo configuration (the ones with the demo certificates etc) as those are well known and thus offer not much in terms of security (see red box warning here)

I refer to this code:

echo "OpenSearch Security Demo Installer"
echo " ** Warning: Do not use on production or public reachable systems **"

which get's run in your default linux install.

which ends up in your officially released packages, which are consumed by openstack kolla-ansible, see the linked warnings/error messages in https://bugs.launchpad.net/kolla-ansible/+bug/2028376.

:edit: formatting

you can find our repository configuration here, as you can see, we are directly consuming your upstream repositories (thanks for providing them!):

https://github.com/openstack/kolla/blob/7f12d216dc4de2c8d32291c3d6223185ecf2b510/docker/base/opensearch.repo#L5

[davidlago]

@artificial-intelligence the default installation has a set of demo certificates and default settings to get it up and running, but any production installation requires more configuration (updating passwords, providing your certificates etc).

I am not familiar with your use case or how you end up running the artifacts you consume from OpenSearch. Are you not providing your own certificates and changing those default passwords too?

FYI we are starting to invest some cycles into securing the default installation out of the box, #1618, starting with the default admin passwords (opensearch-project/security#1576).

[artificial-intelligence]

I'd have to double check, afaik we're providing user provided passwords and certs to opensearch (we are a ansible playbook project to provide production grade playbooks to deploy Openstack in docker containers, for more details and context see: https://docs.openstack.org/kolla/latest/), so that part is handled.

I just found it funny that a script that even says it should not be run in production is included and run by default in debian based operating systems by the official opensearch projects deb builds.

so we bascially install upstreams provided artifacts straight from the repository inside respective docker containers - we provide different containers for different distros.

the efforts to increase security are highly appreciated! 👍

still the question remains - if my analysis is correct - why the security plugin and the installation process for opensearch seem to have a desync when it comes to opinions about file system permissions.

I'd be great if someone more familiar than me could take a look at the provided code parts and confirm that these are indeed run when installing the official deb builds.

I did just reverse engineer this via github search, so I might be wrong, as opensearch is a huge project and it's easy to misunderstand the complex build process.

Thanks!

[davidlago]

still the question remains - if my analysis is correct - why the security plugin and the installation process for opensearch seem to have a desync when it comes to opinions about file system permissions.

Sorry, yes... we have been talking about this "side quest" but the main question is still unanswered. @bbarani / @peterzhuamazon / @prudhvigodithi please make sure this is still on your radar.

[peterzhuamazon]

If this is related to debian/rpm, we are having a discussion here already:

• Defaut config permission too relaxed in deb and rpm packages opensearch-build#3815

[peterzhuamazon]

Close this as it is duplicate to opensearch-project/opensearch-build#3815.