documentation: security best practices for volumes

[gtirloni]

To prevent code inside a container from creating objects that could be potential security holes on the host.

Might also show a warning if a container is started and the filesystem used to mount a volume does not have those options ("the filesystem used allows device, executable and suid files to be created, please consider using a separate filesystem with nodev,noexec,nosuid options").

[alban]

Context: the discussion started from this blog post and on the rkt-dev mailing list.

As far as I understand the scenario in the blog post, the command ./sh to become root (and the following whoami) are executed on the host, and not in the Docker container. So in order to block the scenario described above, the options nosuid would need to be set up on the host mountpoints, rather than on the mountpoints in the container's mount namespace. That's not up to Docker or rkt to decide the mount options on the host. And noexec cannot be used on "/" on the host.

The nosuid option does not block the creation of files with the suid bit, but rather ignore the bit when the file is executed. Similarly, nodev does not restrict the ability to create device nodes, but rather block access to them.

So I don't think it is necessary to change the mount options in the rkt mount namespace. (And it would not help)

I like your idea of a warning.

I suggest we also keep this issue open until the security implications of bind mounting a volume from the host to the pod are properly documented. Security best practices in rkt/Documentation/security.md?

• Use volumes with "readOnly=true" when write access is not necessary
• When write access is necessary, advise to only share directories that are on a
  filesystem mounted with the options nosetuid, nodev.

[gtirloni]

That makes sense. Thanks a lot @alban!

[jonboulle]

Updated title to capture proposal.

[ibukanov]

Mounting with nosuid still allows to create setuid binaries, it is just the setuid bit would have no effect. That leaves a possibility of doing cp -a or similar to transfer setuid binary to another location. This is probably insignificant threat, but still emphasizing in the documentation about avoiding root for processes in the containers would be nice.

[alban]

More ideas for security best practices for volumes:

• it is better if the volume being shared is a full filesystem rather than just a directory in a filesystem (a mounted partition or some file mounted with mount -o loop)
• avoid sharing directories when tools on the host can move files outside the directory (such as Nautilus moving directories to the wastebasket ~/.local/share/Trash when the user deletes it)

See:
moby/moby#12317