Docker compose discussion

[pablomendezroyo]

The docker-compose volumes, networks and service keys/volumes/networks are critical in dappnode since all dappnode packages are distributed through docker-compose.yml files.

service keys
The compose keys may be critical and allow a container to gain privileges on the host and perform almost any type of attack.

In dappnode there is a compose keys "whitelist" to restrict the use of these keys. However this list has been growing due to necessities and it must be reviewed in deep.

To discuss:

• Should the "danger" keys have a whitelist of dappnode package that are allowed to use it? this way would require a core release to add a new package to the list but would be safer so other packages would be restricted to use such key.
• cap_add: used by Mysterium. tropicar could you find another approach to not use that capability? if not, could you explain why capability NET_ADMIN is necessary?
• devices seems to be used nowhere. Should it be removed?
• extra_hosts seems to be used nowhere. Should it be removed?
• logging this value is overwritten during installation time at https://github.com/dappnode/DNP_DAPPMANAGER/blob/947f9196efbb596f4d94ea9d647dd54ed1b295c4/packages/dappmanager/src/modules/compose/unsafeCompose.ts#L99 . Should it be removed ?
• network_host seems to be used nowhere. Should it be removed?
• pid restricted to service:*.
• privileged currently used by dappmanager wifi and vpn. It should be restricted to this small whiltelist
• restart this value is been overwritten during installation time at https://github.com/dappnode/DNP_DAPPMANAGER/blob/947f9196efbb596f4d94ea9d647dd54ed1b295c4/packages/dappmanager/src/modules/compose/unsafeCompose.ts#L98 . . Should it be removed ?
• security_opt used by lighthouse and web3signer. This is necessary due to using newer docker images with old docker engine versions. Docker engine version should be updated on dappnode hosts. See Consider switching docker installation and update method from package to repository #392

networks
There are currently two docker networks for simplicity in dappnode: dncore_network (for all containers) and dnpublic_network (for HTTPS portal mappings). The current setup is that no one owns any docker network, both of them are declared as external. The dncore_network is created on dappnode installation with docker network create. The dnpublic_network is created by the dappmanager when installing the HTTPS package.

To discuss:

• As Fredik security report, having all containers in the same docker network is a security vulnerability since containers can communicate with each other without restrictions, which is not ideal. Implementing a docker network system to have a dedicated docker network for each group of containers looks complicated. What other solutions do we have?
• Should the dnpublic_network be owned by the HTTPS package? see reasoning Define dnpublic_network in the docker-compose.yml DNP_HTTPS#66

volumes
There are two types of docker volumes used in dappnode: named and bind-mounted volumes. Bind mounted volumes are dangerous and should be only used in a reasoned case of necessity (especially the docker socket volume)

To discuss:

• Restrict bind mounted volumes to exporter, wifi, wireguard, vpn core and dappmanager:
  • dappmanager:
    • /run/dbus/system_bus_socket used by avahi and upnp
    • /usr/src/dappnode/DNCORE/ used to have on host the core compose files, and hostScripts
    • /var/run/docker.sock to allow dappmanager to perform docker actions
    • /etc/hostname to render the hostname in the UI. Would be a better solution to run a script to get the hostname on startup instead of bind-mounting the volume? tropicar
  • exporter: as Fredik security report, the exporter is mounting the whole host file system. There should be a way to make the exporter work without this mount.
  • wifi
    • /var/run/docker.sock used to execute container with host network privileges
  • vpn:
    • /var/run/docker.sock ?
    • /etc/hostname ?
    • /usr/src/dappnode/config ?
    • /lib/modules ?
  • wireguard
    • /lib/modules ? 3alpha
  • core:
    • /etc/ to get access to /etc/os-release and /etc/motd files from host. Consider only mounting those files instead of the entire /etc folder
    • /usr/src/dappnode/ to modify scripts and profile
    • /var/run/docker.sock to startup dappmanager container

┆Issue is synchronized with this Basecamp todo by Unito

[dapplion]

You must replace the "seems to be used nowhere" to "I have run a script checking all latest versions and guarantee that as of Jun 20th 2022 it's not used anywhere"

[3alpha]

Regarding exporter package, I've been running for last few days a package without root system exposed and majority of data is there. I think we should just remove rootfs binding because risk greatly overweigh (limited) benefits.

Wireguard needs kernel modules to run.

[dapplion]

Regarding exporter package, I've been running for last few days a package without root system exposed and majority of data is there. I think we should just remove rootfs binding because risk greatly overweigh (limited) benefits.

Wireguard needs kernel modules to run.

Please PR

[tropicar]

cap_add: used by [Mysterium](https://github.com/dappnode/DAppNodePackage-Mysterium/blob/836c62dc76c45aac188772fa8c506e8cd922908f/docker-compose.yml#L10). @tropicar could you find another approach to not use that capability? if not, could you explain why capability NET_ADMIN is necessary?

I don't know exactly why is required, but even in the Mysterium docs, they run the container with that flag by default. When I created the package, the package cant run without that option. I guess it's because the service requires some network permissions. I can ask them if it's possible but I am not so optimistic, but we can try it.
https://docs.mysterium.network/for-node-runners/docker-guide