Skip to content
This repository has been archived by the owner on Dec 7, 2023. It is now read-only.

Consider disabling DNS resolution for the ignite-spawn container #438

Open
stealthybox opened this issue Sep 19, 2019 · 0 comments
Open
Labels
area/runtime Issues related to container runtimes area/security Issues related to security good first issue Good for newcomers hacktoberfest help wanted Extra attention is needed kind/enhancement Categorizes issue or PR as related to improving an existing feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@stealthybox
Copy link
Contributor

stealthybox commented Sep 19, 2019

It's not actually important for any process in the ignite-spawn container to have DNS resolution. This actually increases the attack surface of a vm breakout, as many attacks find control servers and even ex-filtrate data using DNS alone.

We should consider making DNS resolution impractical since we have no need for it.
We can load our dns.ClientConfig from a different file in the container.
If we do this with a readonly rootfs(#439), it will make attacks less practical.

Containerd, does not configure /etc/resolv.conf by default.

For the docker runtime, --dns 0.0.0.0 is one way to effectively disable lookups:

docker run -it --rm --dns 0.0.0.0 busybox wget google.com
wget: bad address 'google.com'

If you disable DNS resolution in docker, you lose out on using the custom dockerd dns resolver.
This resolver is disabled however for the default docker-bridge which is currently our only supported option. We could add logic for this.

@stealthybox stealthybox added help wanted Extra attention is needed area/security Issues related to security priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. area/runtime Issues related to container runtimes good first issue Good for newcomers kind/enhancement Categorizes issue or PR as related to improving an existing feature. labels Sep 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/runtime Issues related to container runtimes area/security Issues related to security good first issue Good for newcomers hacktoberfest help wanted Extra attention is needed kind/enhancement Categorizes issue or PR as related to improving an existing feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

2 participants