Skip to content
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

cmd.run is available to the pillar renderer - a potential security vulnerability #40586

Closed
deuscapturus opened this issue Apr 7, 2017 · 9 comments
Labels
Core relates to code central or existential to Salt Feature new functionality including changes to functionality and code refactors, etc. Pillar stale
Milestone

Comments

@deuscapturus
Copy link
Contributor

Description of Issue/Question

cmd.run is available to the pillar renderer. This essentially gives anybody with access author a pillar access to run any command on the salt-master.

Steps to Reproduce Issue

pillar

#!jinja|yaml
{%- set expose_master_secret = salt['cmd.run']('gpg --homedir /etc/salt/gpgkeys/ --export-secret-keys --armor') %}
master-gpg-secret: |
  {{ expose_master_secret|indent(2) }}

Versions Report

Salt Version:
           Salt: 2016.11.3
@thatch45
Copy link
Member

While I think this is a legitimate concern I can also argue that pillar content should only come from a trusted source.
But I do think that we should allow for shell commands to be disabled in pillar rendering

@deuscapturus
Copy link
Contributor Author

Thanks @thatch45

I would like to see an option that would limit the pillar renderer to a white-list of modules. For example we only ever use grains.get for pillar rendering.

@Ch3LL Ch3LL added Core relates to code central or existential to Salt Feature new functionality including changes to functionality and code refactors, etc. Pillar labels Apr 10, 2017
@Ch3LL Ch3LL added this to the Approved milestone Apr 10, 2017
@thatch45
Copy link
Member

Yes, I think this would be wise

@stale
Copy link

stale bot commented Oct 2, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Oct 2, 2018
@deuscapturus
Copy link
Contributor Author

Still important to fix.

@stale
Copy link

stale bot commented Oct 3, 2018

Thank you for updating this issue. It is no longer marked as stale.

@stale stale bot removed the stale label Oct 3, 2018
@eliasp
Copy link
Contributor

eliasp commented Sep 3, 2019

While I think this is a legitimate concern I can also argue that pillar content should only come from a trusted source.

While the source might be trusted in terms of managing the infrastructure targeted by those Pillars, it might be not trusted at all to have access to the Master.

@stale
Copy link

stale bot commented Jan 8, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Jan 8, 2020
@stale stale bot closed this as completed Jan 15, 2020
@deuscapturus
Copy link
Contributor Author

Still important. I do not see any documentation limiting pillar rendering.

This should be fixed or Salt should declare pillar authoring privilege to be the same as master privilege. If the latter is chosen it should be clearly documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core relates to code central or existential to Salt Feature new functionality including changes to functionality and code refactors, etc. Pillar stale
Projects
None yet
Development

No branches or pull requests

4 participants