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

File paths may not step up. #693

Closed
monopole opened this issue Jan 11, 2019 · 1 comment · Fixed by #700
Closed

File paths may not step up. #693

monopole opened this issue Jan 11, 2019 · 1 comment · Fixed by #700

Comments

@monopole
Copy link
Contributor

monopole commented Jan 11, 2019

Currently, all file paths mentioned in a kustomization file must be defined relative to the location of the kustomization file.

This allows (e.g.) the following fishing attack. Someone writes a kustomization with a configmap generator that reads data from ../../../etc/passwd, and sends it to a victim, hopes the victim performs the kustomization in the correct working directory, and hopes to subsequently look at the cluster to see the data.

To prevent this, the following restriction is added:

All files paths mentioned in a kustomization file (resources, patches, config data) must refer to files in or below ., the location of the kustomization file.

Bases are not subject to this, and may be specified as living in sibling directories (or in remote URLs). A base can be viewed as an “import”, and its data files are subject to the same restriction but relative to that base.

Symlinks will be purged (e.g. via filepath.EvalSymlinks).

@arash-bizcover
Copy link

This compulsory security feature is ridiculous @monopole
This avoids us using a genuine use case of template files outside of project files. You should have made it optional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants