On Thu, Jun 04, 2020 at 03:33:25PM -0500, Eric W. Biederman wrote: > Alexey Gladkov <gladkov.ale...@gmail.com> writes: > > > Greetings! > > > > Preface > > ------- > > This patch set can be applied over: > > > > git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git > > d35bec8a5788 > > I am not going to seriously look at this for merging until after the > merge window closes.
OK. I'll wait. > Have you thought about the possibility of relaxing the permission checks > to mount proc such that we don't need to verify there is an existing > mount of proc? With just the subset pids I think this is feasible. It > might not be worth it at this point, but it is definitely worth asking > the question. As one of the benefits early propopents of the idea of a > subset of proc touted was that they would not be as restricted as they > are with today's proc. I'm not sure I follow. What do you mean by the possibility of relaxing the permission checks to mount proc? Do you suggest to allow a user to mount procfs with hidepid=2,subset=pid options? If so then this is an interesting idea. > I ask because this has a bearing on the other options you are playing > with. I can not agree with this because I do not touch on other options. The hidepid and subset=pid has no relation to the visibility of regular files. On the other hand, in procfs there is absolutely no way to restrict access other than selinux. > Do we want to find a way to have the benefit of relaxed permission > checks while still including a few more files. In fact, I see no problem allowing the user to mount procfs with the hidepid=2,subset=pid options. We can make subset=self, which would allow not only pids subset but also other symlinks that lead to self (/proc/net, /proc/mounts) and if we ever add virtualization to meminfo, cpuinfo etc. > > Overview > > -------- > > Directories and files can be created and deleted by dynamically loaded > > modules. > > Not all of these files are virtualized and safe inside the container. > > > > However, subset=pid is not enough because many containers wants to have > > /proc/meminfo, /proc/cpuinfo, etc. We need a way to limit the visibility of > > files per procfs mountpoint. > > Is it desirable to have meminfo and cpuinfo as they are today or do > people want them to reflect the ``container'' context. So that > applications like the JVM don't allocation too many cpus or don't try > and consume too much memory, or run on nodes that cgroups current make > unavailable. Of course, it would be better if these files took into account the limitations of cgroups or some kind of ``containerized'' context. > Are there any users or planned users of this functionality yet? I know that java uses meminfo for sure. The purpose of this patch is to isolate the container from unwanted files in procfs. > I am concerned that you might be adding functionality that no one will > ever use that will just add code to the kernel that no one cares about, > that will then accumulate bugs. Having had to work through a few of > those cases to make each mount of proc have it's own super block I am > not a great fan of adding another one. > > If the runc, lxc and other container runtime folks can productively use > such and option to do useful things and they are sensible things to do I > don't have any fundamental objection. But I do want to be certain this > is a feature that is going to be used. Ok, just an example how docker or runc (actually almost all golang-based container systems) is trying to block access to something in procfs: $ docker run -it --rm busybox # mount |grep /proc proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) proc on /proc/bus type proc (ro,relatime) proc on /proc/fs type proc (ro,relatime) proc on /proc/irq type proc (ro,relatime) proc on /proc/sys type proc (ro,relatime) proc on /proc/sysrq-trigger type proc (ro,relatime) tmpfs on /proc/asound type tmpfs (ro,seclabel,relatime) tmpfs on /proc/acpi type tmpfs (ro,seclabel,relatime) tmpfs on /proc/kcore type tmpfs (rw,seclabel,nosuid,size=65536k,mode=755) tmpfs on /proc/keys type tmpfs (rw,seclabel,nosuid,size=65536k,mode=755) tmpfs on /proc/latency_stats type tmpfs (rw,seclabel,nosuid,size=65536k,mode=755) tmpfs on /proc/timer_list type tmpfs (rw,seclabel,nosuid,size=65536k,mode=755) tmpfs on /proc/sched_debug type tmpfs (rw,seclabel,nosuid,size=65536k,mode=755) tmpfs on /proc/scsi type tmpfs (ro,seclabel,relatime) For now I'm just trying ti create a better way to restrict access in the procfs than this since procfs is used in containers. -- Rgrds, legion
