> The fix included patching the init function of docker-tar to call arbitrary functions from the problematic Go packages. This forced docker-tar to load the libnss libraries before chrooting to the container, and thus from the host filesystem.
This seems like a band aid, not a proper fix. docker-tar is still run, chrooted into the untrusted container root directory, but in the host's namespace (i.e., ubcontained). As we all know, chroot on Linux is not a security barrier!
I think it would be better to run one docker-tar entirely inside the container, writing to a socket; with another docker-tar on the host reading from the other end of the socket.
Taking a step back though I have to ask why 'docker cp' has to execute anything at all. I would not expect that copying files would need to do anything other than open files within the container and read them. I suppose this would only be possible if the open syscall had a way to prevent symlinks being followed (O_NOFOLLOW is not sufficient because it only applies to the final file in the path, not any parent directories).
This seems like a band aid, not a proper fix. docker-tar is still run, chrooted into the untrusted container root directory, but in the host's namespace (i.e., ubcontained). As we all know, chroot on Linux is not a security barrier!
I think it would be better to run one docker-tar entirely inside the container, writing to a socket; with another docker-tar on the host reading from the other end of the socket.
Taking a step back though I have to ask why 'docker cp' has to execute anything at all. I would not expect that copying files would need to do anything other than open files within the container and read them. I suppose this would only be possible if the open syscall had a way to prevent symlinks being followed (O_NOFOLLOW is not sufficient because it only applies to the final file in the path, not any parent directories).