Why does helm package follow symlinks?

[ibuildthecloud]

I'm trying to write some automation that will run "helm package" on arbitrary and possibly untrusted content. The fact that helm package will follow symlinks introduces a security concern in that 1) content outside the chart root can be read and 2) I believe it's possible to create an infinite loop. Why does helm need support symlinks and could it be possible to disable this behaviour optionally?

[lingsamuel]

I think we need something like https://github.com/cyphar/filepath-securejoin

[bacongobbler]

A couple of things to note here.

1. Symbolic links followed beyond the chart root are followed, and the content is copied at the time of helm package along with a warning. This was addressed as part of the security audit last year, resulting in a new release of Helm 2, and was addressed before Helm 3.0.0 was released. More info is available in the blog post.
2. No, there is no way to disable this behaviour.

[bacongobbler]

Infinite loops are not possible either, as that was addressed in ee8cd8b.

That should hopefully address all of your concerns. Is there some other action item that should be addressed here, or can we close this?

[ibuildthecloud]

@bacongobbler Just to clarify. Is it correct to say that in Helm 3, helm package should not be run on untrusted content. There is no mitigation in place that prevent symlinks from linking to content out of the chart root dir.

It sounds like some thought went into this, so I don't expect any change but just need to clearly understand what mitigation I need to put in place. Thanks!

[bacongobbler]

Just to clarify. Is it correct to say that in Helm 3, helm package should not be run on untrusted content.

At the very least, helm package is assumed to be run in a sandboxed environment.

There is no mitigation in place that prevent symlinks from linking to content out of the chart root dir.

In terms of outright disallowing helm package to resolve symlinks, no. There is some sanity checking such as disallowing irregular files like /dev/random from being symlinked into the package, but otherwise it is free to package anything within the system so long as the user has the correct permission rights to do so.

In addition, there are warnings reported when a symbolic link is used to inform the user that the chart is linking in external files:

walk.go:74: found symbolic link in path: ... (paths elided) ...

But we don't disallow users from symlinking external files into the chart.

In terms of mitigation, you could change the file mode bits for files you do not wish the untrusted user to link to. For example, you could create a helmpack group which does not have read/write permission to anything but the chart directory, but you could still provide them execution permissions on /bin. That way, symbolic links cannot resolve to files outside of the chart directory.

I have not tested this myself, but I'm fairly confident that should solve your use case.

Does that help?

[mattfarina]

@ibuildthecloud With Helm we have classified people into different roles. They are often not the same people filling them. Two of the roles are the chart creator and then the helm/chart user. For example, a company like Bitnami would package up mariadb as a chart creator and then many people would install the chart as a Helm/chart user. Bitnami as the chart creator would use helm package while the Helm/chart user would not need to. They get the packaged archive.

What use cases do you have for people running helm package in untrusted situations?

[bacongobbler]

closing as answered/inactive.