Allow for '/' in context name

[jvassev]

Also, fix kubens - which fails to save previous namespace
after 6610d70

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[jvassev]

I signed it

[googlebot]

CLAs look good, thanks!

[ahmetb]

Thanks a lot for catching this. It's indeed an edge case. Do you manually maintain your kubeconfig entries? I'm curious what generates a context name with / in it. :)

[ahmetb]

I'm trying to understand why this exists. Can you explain?

[jvassev]

As you said in 6610d70, the https://github.com/koalaman/shellcheck/wiki/SC2155 prevents masking the return value. In case $f does not exists the return value is 1, and since you're using set -eou this aborts the script.

A non-existent file in this case is just fine, so I again mask the return value

[ahmetb]

I see it now when I executed it myself with DEBUG=1 ./kubens. Thanks so much for noticing this.

I guess this works, because in both places read_namespace is called, empty output will do the job.

[ahmetb]

do you mind creating a

escape_context_name() {
    echo "${1//\//-}"
}

and using it here?

[jvassev]

sure, added it.

[jvassev]

I am renaming the contexts generated by a tool :) There are just too-many-dashes-in-the-generated-name. I needed a delimiter other than - or _ and one that implies hierarchy. Slashes won the contest :)

[ahmetb]

I see it now when I executed it myself with DEBUG=1 ./kubens. Thanks so much for noticing this.

I guess this works, because in both places read_namespace is called, empty output will do the job.

[ahmetb]

@jvassev Thank you for your patch and debugging the subtle issue with the return value.

If you're interested in development of the project, please hit "Watch" so you can participate in issue discussions and feature proposals.

[ahmetb]

@jvassev Now that v0.5.0 is released a couple of days ago, I'd like to thank you again.

Your fix highlighted what was a security vulnerability in kubens.

Summary

kubens was susceptible to an attack where a crafted context with a name like ../../.bashrc could potentially overwrite any executable file on the filesystem the user has write permissions to, and cause arbitrary code execution.

This is because kubens uses the name of the current-context to save the previous namespace (for kubens - feature to work). When the context name contains relative paths, the path $HOME/.kube/kubens/../../.bashrc is evaluated to $HOME/.bashrc.

Exploitability

Unless the user picks up an untrusted kubeconfig file and starts using that, OR they let a program/user to change their existing kubeconfig (through kubectl config), this is not exploitable. This is also not remotely exploitable. Which makes this a low severity vulnerability.

Normally, Kubernetes validates the format for namespaces. However an attacker can also bypass this by setting an arbitrary "namespace" field on the context (in kubeconfig file, or through kubectl config set-context --namespace=...). This lets the attacker set arbitrary contents for the cache file used by kubens (which can be spoofed to be written to any path).

PoC Exploit

1. Check out v0.4.1 (8033613),
2. Rename the current context to ../../.bashrc2
3. kubectl config set-context $(kubectl config current-context) --namespace="echo Hello"
4. Run ./kubens default, (this triggers current-namespace value to be saved to a file)
5. cat ~/.bashrc2, observe the file contains echo Hello.