-
Notifications
You must be signed in to change notification settings - Fork 273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defaut config permission too relaxed in deb and rpm packages #3815
Comments
Cc @peterzhuamazon and @mnin who contributed to the awesome Debian packaging and might have an opinion on this! |
Tagging @peterzhuamazon to take a look. |
Hi @smortex I am currently a bit busy on another project. I think in the rpm pkg I did something on the spec file for such permissions, but in deb pkg I assume there might have missed something in the user scripts. Thanks. |
It seems ownership & permission-bits set by the DEB & RPM packages are similar, if not the same. For reference, here they are from OpenSearch 2.9.0-1 RPM package:
I suppose 3 new lines could be introduced to the build_templates/ opensearch.rpm.spec & postinit to set the same file permission-bits as the Tar-file does? I created PR #3858 to propose these changes.
|
Hey @smortex, thank you for the inquiry! I was looking into this together with @etgraylog. We checked the DEB and RPM results in the OpenSearch-build is calling the This https://github.com/opensearch-project/security/blob/main/tools/install_demo_configuration.sh might be the right place to adjust the file permissions for security related directories and files. @peterzhuamazon what do you think? |
Hi, In tar, the install demo configuration is also run, so if tar is preserving the permissions after running the script, rpm/deb should have the same. It seems like I think that install demo configuration script is going away at some point, so I am hesitate to introduce more changes in there or just fix with the closing #3858. Tho even then, #3858 is putting lines in the wrong location where if security plugin is not present, the building of the pkgs will fail. I am ok to re-open #3858 and fix it through the spec file/post script tho. Let me know, Thanks. |
The repository that the PR was created from has already been deleted, so I don't think the PR can be re-opened. Moving the lines proposed in #3858 for Of course we can also consider an entirely different approach that would change What do you think @mnin @peterzhuamazon ? |
The tar archive permissions do not allow any permissions for "others", so we can stick to that, this seems okay. |
I think I remembered why I add the line: I skipped As a result, in order to make sure the permission is consistent, I manually copied this from the output into install |
as already said in the linked issue opened by me, I was not aware that there already was an open issue about this. I still think this setting in gradle also might play a role in the insecure permissions? But I'm not sure, as I'm not really familiar with the opensearch build process. Knowing a thing or two about deb/rpm packaging I think it's safe to say that permission setting should be part of the package spec, e.g. post sections in the package. Thanks for working on this and thanks to @peterzhuamazon for making me aware of this issue. |
When we release deb/rpm we extract all the files from the deb/rpm min pkg from opensearch core repo, install plugins, then repackage with either debmake or rpmbuild, and both of them is running So the solution right now is one of these:
Want to get thoughts from you guys on which to approach here, @mnin @smortex @etgraylog @artificial-intelligence . Thanks. |
Have some offline talk with @smortex and he is currently looking into this. Thanks. |
Hey everyone! With @peterzhuamazon help I could finally build .deb and .rpm packages on my work machine and could iterate to have packages that better fit my expectations. I opened #3898 with these fixes and invite you to give it a try. For information, I built test packages (deb and rpm) using the following on Debian 11 (these are "minimal" packages with just OpenSearch core and the security plugin but nothing more): Building a deb:
Building a rpm:
Thank you! |
Lol, I was wondering why the SGID bit was set on the /etc/opensearch directory on REHL but this seems to be the culprit. I saw no reason for it so removed it when building the rpm (the debian packaging seems to strip it automatically). This code was added in opensearch-project/OpenSearch@2cf7a80 but the issue referenced in the commit message does not exist. I don't see the reason for this SGID bit and think we can remove it, but maybe someone has an idea about why this was introduced and we should keep it? |
Sync @nknize and @reta in this conversation about the bit, thanks. |
New changes: There are some concerns on this change go into 2.10.0 as follows:
We have a offline discussion with @smortex and we agree on the next steps:
Thanks. cc: @smortex @mnin @etgraylog @artificial-intelligence @bbarani @gaiksaya @peterzhuamazon |
We have presented the above change in community meeting today (2023/10/17). cc: @smortex @mnin @etgraylog @artificial-intelligence @bbarani @krisfreedain |
After installing the Debian package, all users can read all configuration files:
Some of these files contain or can contain sensitive data, for example:
internal_users.yml
contain hashed password;config.yml
can contain clear-text credential for authentication against an LDAP directory.Upon initial investigation, this is the result of this
chmod
on the whole tree of files installed by the package:opensearch-build/scripts/pkg/build_templates/opensearch/deb/debmake_opensearch_install.sh
Line 44 in b422ae0
It looks like the tarball of OpenSearch has different and more restrictive permissions by default
config
(read/etc/opensearch
with the Debian package)config/opensearch.yml
config/opensearch-security
config/opensearch-security/*.yml
I am opening this issue in order to discuss this packaging issue and fix it. IMHO, the tarball default permissions are better than the Debian ones, but there is still room for improvement such as changing files ownership to root:opensearch in order to prevent a compromised service from rewriting it's configuration (and yes, currently all the files installed by the package are owned by the opensearch user so he can overwrite all the application code, but let's tackle this in another PR).
What do you think?
The text was updated successfully, but these errors were encountered: