On 2018-04-04, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > The following commands show my problem: > > > > $ sudo docker run -ti --rm --cap-add=SYS_ADMIN busybox sh -c 'unshare -U -r -p -m -f mount -t proc proc /home && echo ok' > > mount: permission denied (are you root?) > > > > $ sudo docker run -ti --rm --cap-add=SYS_ADMIN busybox sh -c 'mkdir -p /unmasked-proc && mount -t proc proc /unmasked-proc && unshare -U -r -p -m -f mount -t proc proc /home && echo ok' > > ok > > Actually this does not show your problem because it does not reveal why > you need to mount proc. > > That is a ``Doctor it hurts when I do this'' example where the Doctor > will reasonably tell you ``Don't do that then''. The context is that people want to run unprivileged runc inside a Docker container, and mounting proc is part of setting up a container. But Docker (and runc) have masks for /proc to stop containers from being able to touch things like /proc/scsi and so on. The other possibility is to give people an escape-hatch when setting up a container which basically says "make this container slightly less secure so that I can run containers inside it". However I share your concern about the layer mixing with inheriting the masks for the new procfs mount (what if you have a mount over a particular process, now the mask is masking something completely different, and a bunch of other possible problems). > > For my use case, I will need to support at least the following entries: > > > > $ sudo docker run -ti --rm busybox sh -c 'mount|grep /proc/' > > proc on /proc/asound type proc (ro,nosuid,nodev,noexec,relatime) > > proc on /proc/bus type proc (ro,nosuid,nodev,noexec,relatime) > > proc on /proc/fs type proc (ro,nosuid,nodev,noexec,relatime) > > proc on /proc/irq type proc (ro,nosuid,nodev,noexec,relatime) > > proc on /proc/sys type proc (ro,nosuid,nodev,noexec,relatime) > > proc on /proc/sysrq-trigger type proc (ro,nosuid,nodev,noexec,relatime) > > tmpfs on /proc/kcore type tmpfs (rw,context="...",nosuid,mode=755) > > tmpfs on /proc/latency_stats type tmpfs (rw,context="...",nosuid,mode=755) > > tmpfs on /proc/timer_list type tmpfs (rw,context="...",nosuid,mode=755) > > tmpfs on /proc/sched_debug type tmpfs (rw,context="...",nosuid,mode=755) > > tmpfs on /proc/scsi type tmpfs (ro,seclabel,relatime) > > It looks like a cruft free cousin of proc that is just processes would > be applicable to your usecase. I think a procfs that only has processes would be a massive improvement for a bunch of other reasons too. :D -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
