RFE: --read-only: add sub-option to make /dev readonly as well

[martinetd]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind feature

Description

podman run --read-only leaves /tmp, /var/tmp /run (tmpfs with default 50% size of ram), /dev (tmpfs with 64MB) and /dev/shm (default 64MB).

• There is --read-only-tmpfs to skip mounting /tmp /var/tmp, and /run

• There is --shm-size which allows changing /dev/shm size (although --shm-size=0 means unlimited, so there is no way of forbidding writes to /dev/shm -- at best you can set size to e.g. 1 which will allow creating a single file <4k then fail with ENOSPC (or create a few hundred thousands of empty files which would consume roughly as many megabytes of memory...))

• And I do not see any option at all for /dev, so a container could also create arbitrary files there (and consume a few hundred MBs of memory creating as many empty files as they can then filling one up)

Would it make sense to also be able to limit these accesses, e.g. not mount /dev/shm at all, and remount /dev as read-only after devices have been created? (works fine doing it manually in a privileged container)

It's always possible to limit the container memory with -m, so my consuming memory argument above is work-aroundable, but the main point here is to have no directory writable at all to limit the attack surface: being able to download an arbitrary binary in /dev and executing it is easier than trying to modify running programs code.
Saying the container is read-only but allowing writes in /dev is a bit counter-intuitive in my opinion.

[giuseppe]

you could achieve something like that with:

$ podman run  --mount=type=tmpfs,target=/dev,ro=true -v /dev/null:/dev/pts -v /dev/null:/dev/shm --rm  alpine cat /proc/self/mountinfo

mounting /dev read-only is tricky though. The OCI runtime itself can fail (both runc and crun do not handle it correctly) and handling of TTYs can also be affected.

Using the command above, I've found an issue in crun: containers/crun#857

[rhatdan]

If you mount /dev readonly, then can you still write to the devices?

[rhatdan]

--read-only-tmpfs should probably include /dev/shm and potentially set /dev to be read-only if that would be allowed.

[rhatdan]

sh-5.1# podman run -v /usr:/usr --privileged -ti fedora sh
sh-5.1# mount -o remount,ro /dev
sh-5.1# touch /dev/dan
touch: cannot touch '/dev/dan': Read-only file system
sh-5.1# echo hello > /dev/null 

Looks like it should work.

[martinetd]

@giuseppe thanks for the idea!

for /dev/shm, using --mount type=tmpfs,target=/dev/shm,ro=true as well is a bit closer to what I want (will get EROFS errors instead of "not a directory") and works quite well, I'll be using that until/if read-only-tmpfs takes care of it :)

I don't think masking /dev/pts is necessary, it's a different mount but it's a special kernel mount type that doesn't allow creating arbitrary files, it's a bit like the many filesystems in /sys even root will just get permissino denied if they just try to create a file naively.

/dev itself is a bit more tricky though because we'd want to leave it read-write while the OCI runtime populates it and only turn it readonly before passing the ball on to the container. It might be possible to get something working by manually mounting all required devices individually but I don't think I want to get down that hole... :)
(This made me try to adjust the size with --mount type=tmpfs,target=/dev,tmpfs-size=xxx but that seems to break the device creations as well even if it's read-write)

@rhatdan yes, remounting /dev read-only is fine, you just need devices to preexist (so a container that would handle hotplug (because e.g. it's privileged and runs udev) won't work, but a normal container where the oci runtime creates devices at start will work). Thanks for taking a look as well :)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.