-
Notifications
You must be signed in to change notification settings - Fork 3k
Description
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.