Podman includes host /etc/hosts in container /etc/hosts

[pboguslawski]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

podman run includes /etc/hosts records from host into /etc/hosts in container; this is security issue; podman should extend existing /etc/hosts from image (or create from scratch if absent) for container only with its own records and records added explicity by admin with --add-host, similar like docker works

https://docs.docker.com/engine/reference/run/#managing-etchosts

/etc/hosts on host may contain stuff that should not be known for container, i.e. addresses of other containers on same machine, hidden from given container, external network names not available for container, etc.

Output of podman version:

# podman version
Version:      3.0.1
API Version:  3.0.0
Go Version:   go1.15.9
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.6
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 2
  distribution:
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: [...]
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.0-8-amd64
  linkmode: dynamic
  memFree: 686698496
  memTotal: 4122234880
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    selinuxEnabled: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 2147479552
  swapTotal: 2147479552
  uptime: 35m 20.97s
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 14
    paused: 0
    running: 14
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 15
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.9
  OsArch: linux/amd64
  Version: 3.0.1

Package info (e.g. output of rpm -q podman or apt list podman):

# dpkg -s podman | grep Version
Version: 3.0.1+dfsg1-3+b2

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

No

Additional environment details (AWS, VirtualBox, physical, etc.):

[mheon]

I had to double-check against Docker to verify their behavior, but you are correct - they base their /etc/hosts for non---net=host containers off the container's /etc/hosts, not the hosts'. I'm amazed this made it three years without being noticed.

I would consider this a breaking change, so I think this is 4.0 only, no backporting.

[rhatdan]

Yes this should definitely be fixed in 4.0

[rhatdan]

Interested in opening a PR to fix?

[pboguslawski]

I would consider this a breaking change, so I think this is 4.0 only, no backporting.

Why not to disable leaking /etc/hosts with new, more general flag like in

#11836 (comment)

This won't be breaking change and may be safely backported probably.

[AkihiroSuda]

/etc/hosts on host may contain stuff that should not be known for container, i.e. addresses of other containers on same machine, hidden from given container, external network names not available for container, etc.

I don’t think /etc/hosts can be a security boundary. Is there any (legacy) product that treats hostnames / IP addresses as “credentials”?

I think the default behavior should remain importing /etc/hosts from the host, but a new CLI flag can be added to change the behavior.

[mheon]

Most of my urge to move to using the container's /etc/hosts as a base is to improve our Docker compat - but, then again, no one has complained about this in two years, and the current complaint is security-based, not because it caused any actual functional issues...

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[baude]

@cdoern can you see this through to completion?

[cdoern]

sure @baude I'll start working on it this week.

[rhatdan]

What should be the name of the option?

--noleak (And block the leaking of /etc/resolv.conf and /etc/hosts into the container? Any others?

Or just
--nohosts

[rhatdan]

Well we already have --no-hosts, so --share-hosts might be better.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

podman 4.0 has this feature.