ping @tonistiigi @justincormack @kolyshkin PTAL

There are not plenty of places where there is a writeable tmpfs, currently there is only one that is not yet removeable (/dev/mqueue which acts as a tmpfs). Since we added --ipc=none support recently we removed the second to last one, so we are close to being able to have totally unwriteable containers. So I am not in favour of always making /dev writeable always. I don't mind adding an option to make it writeable, or even the reverse, so long as there is a way to make it not writeable.

/dev/shm?

What is the goal of --readonly. I see it as preventing a process from making changes to the image. Not to where it can not write on any temporary file system.

       --read-only=true|false
          Mount the container's root filesystem as read only.

docker run --help  | grep root-readonly
      --read-only                   Mount the container's root filesystem as read only

Man page and help indicate that the "root" file system is readonly not all file systems inside of the image.

--ipc=none removes /dev/shm. I think the wording is a bit unclear, and while yes in theory it was the rootfs, which corresponds exactly to the runtime spec config, it always affected some other filesystems. I would be happy if these were affected by other flags instead.

I guess I don't understand the goal of --read-only flag then. The way I would describe it, is the flag gives a security feature where a container can not modify the image used for it, and just restarting the container would remove any content created by processes running inside the container, except for content volume mounted into the container.

If your definition is that --read-only means that the processes can not write to anywhere inside of the container except for volumes mounted into the container, then you are failing at that by overriding

"/proc", "/dev/pts", "/dev/mqueue":

IE Processes would be able to write to /dev/pts, and /dev/mqueue, as well as able to write to /proc.

# docker run --read-only -ti fedora mount | grep rw
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,context="system_u:object_r:container_file_t:s0:c163,c465",gid=5,mode=620,ptmxmode=666)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime,seclabel)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:container_file_t:s0:c163,c465",size=65536k)
devpts on /dev/console type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000)

By either definition --read-only is broken.

From a security point of view, the security goal is that by default a hacked container can not write a backdoor so that if the container was restarted it would be already compromised.

I actually believe all containers in production should run with --read-only rootfs, with /run /var/tmp, /tmp with tmpfs mounted and writing to /dev/*, Buf if users need to do lots of toggling of flags to make tmpfs work, then --read-only will hardly ever being used, which means we miss an opportunity to make containers more secure.

ping @n4ss as well (for entitlements)

You cant actually write stuff to /dev/pts as it is a proper pseudo filesystem that only accepts pty nodes not arbitrary files.

However, having discovered that you can create a file using memfd_create and then use execveat to execute it, I hereby give up on not providing writeable tmpfs to containers, so I guess this change is ok...

@thaJeztah Tests pass who else do I need to get approval from to get this merged?

ping @justincormack @kolyshkin PTAL

LGTM

I admit I also do not entirely understand why --read-only is not specific to container's rootfs only. Was it done as a way to prevent creating/running a new binary?

However, having discovered that you can create a file using memfd_create and then use execveat to
execute it, I hereby give up on not providing writeable tmpfs to containers, so I guess this change is ok...

Can seccomp be used to disallow memfd_create?

Also, /dev is (hopefully) mounted with noexec so you can't really run a binary from it.

Oops, looks like it's not

kir@kd:~$ docker run -it alpine mount | grep 'on /dev '
tmpfs on /dev type tmpfs (rw,nosuid,size=65536k,mode=755)

Unless there's something we need to run from /dev, I think this "no-noexec" should be fixed before merging this PR.

@justincormack would it makes sense to do the following as part a fs.read-only entitlement?

• prevent memfd_create syscall
• remove /dev/shm

I get the feeling that the only real read-only is going to come from IMA+EVM..

I agree with @kolyshkin, let's make sure /dev has the most restrictive mount option besides ro (even as part of this PR).

well, memfd_create is really useful and I have lots of code that uses it...

I did think /dev was mounted noexec I will have to check if it changed at some point.

I think we can change `noexec`` in another pr, it is unrelated.

I agree we can do the other changes in a follow-up

@n4ss @kolyshkin could one of you make a pull request or open an issue to track that effort?

@thaJeztah #35397