Parity does not work out of the box with Docker Compose/Swarm

[MicahZoltu]

• Parity Ethereum version: v2.2.6-beta-e9396e1-20190109
• Operating system: Linux
• Installation: Docker
• Fully synchronized: N/A
• Network: N/A
• Restarted: N/A

The following run-of-the-mill docker-compose/swarm file will not function correctly and instead error as described in #9827. this issue was debated a bit over in #9689 but at the time I (and I think others) didn't fully realize that the problem is not just "can't upgrade parity version automatically" but actually is a more fundamental problem that makes it so you cannot run the official docker images via Docker Swarm.

version: '3.6'
services:
  parity:
    command: '--base-path /mnt'
    #entrypoint: '/home/parity/bin/parity'
    image: 'parity/parity:stable'
    #user: 'root'
    volumes:
      - type: 'volume'
        source: 'parity'
        target: '/mnt'
    #working_dir: '/home/parity'
volumes:
  parity:
    external: true

If you uncomment the selected lines you can get it working by bypassing the startup script, but this has the notable risk that a future docker image update may become backward incompatible because you are using a custom entrypoint.

Ideally, I think Parity should revisit the "run as parity user inside the docker image" decision as I think that is just security theater rather than actual security. Second to that, someone should fix the docker image so that it actually works out of the box in common environments (like docker swarm).

[seanturner83]

"Ideally, I think Parity should revisit the "run as parity user inside the docker image" decision as I think that is just security theater rather than actual security." - you are actually joking right? Here's a very clever person's take on your "theater" https://opensource.com/article/18/3/just-say-no-root-containers

[MicahZoltu]

I read over that, plus the 3 articles linked at the top, and my position hasn't changed. It is possible I'm slow, or don't understand Linux security well enough, or am otherwise missing the point, but in all of these articles I fail to see a real attack vector that is being defended against. That is, none of the articles that say "don't use root inside the container" clearly explain (in words I can understand) what the attack vector they are defending against is, or what their threat model is like.

I am interested in finding a good explanation of an actual attack vector that is made possible by running processes in a container as root where the attacker doesn't also need the user to do something crazy like "mount the root filesystem". However, every time I find an article like the one above, it talks a bunch about theory but never explains an attack vector in words that I can understand.

[seanturner83]

Try this: https://sysdig.com/blog/7-docker-security-vulnerabilities/

[MicahZoltu]

I read through it, unless I am misunderstanding, it is talking about running the docker daemon as a limited user, not about things inside the container having root within the container. I tend to agree with the general guidelines presented in that article, but I don't believe they have to do with this issue (which is that Parity changed the user it is running as inside the container).

[taoeffect]

Since I use username namespace remapping it shouldn't matter much to me whether or not the default user is root, however, not everyone does that and it is most definitely not "security theater" to add additional restrictions to a process, and I would prefer (if possible) that processes not be run as root, even in containers. Making them root is just lazy and could lead to potential vulnerabilities.

Whenever you remove restrictions (add capabilities and "features"), you are increasing attack surface. An increase in attack surface = less secure.

So I applaud Parity's decision to not run the process as root, and do not recommend changing that. This issue can surely be fixed without requiring root anyway. It looks like a normal unix permissions issue.

[MicahZoltu]

I certainly won't argue that running processes inside of containers with less privileges is going to make security worse, and there is an argument that it makes things marginally better.

My argument is merely that the difference in security is negligible and given that the change was breaking for existing users and has made it so some common workflows (like Docker Compose and Docker Swarm) no longer work, I don't think the change was prudent/pragmatic.

That being said, the primary point of this particular issue is to advocate to fix the now broken workflows (compose/swarm). If that can be done while leaving the user as not-root then I would accept this issue as resolved, even though I prefer the root solution.