From: Alexey Gladkov <firstname.lastname@example.org>
To: "Eric W. Biederman" <email@example.com>
Cc: LKML <firstname.lastname@example.org>,
Linux FS Devel <email@example.com>,
Alexander Viro <firstname.lastname@example.org>,
Alexey Dobriyan <email@example.com>,
Andy Lutomirski <firstname.lastname@example.org>,
Kees Cook <email@example.com>,
Linux Containers <firstname.lastname@example.org>
Subject: Re: [PATCH 0/2] proc: use subset option to hide some top-level procfs entries
Date: Fri, 5 Jun 2020 02:08:38 +0200 [thread overview]
Message-ID: <20200605000838.huaeqvgpvqkyg3wh@comp-core-i7-2640m-0182e6> (raw)
On Thu, Jun 04, 2020 at 03:33:25PM -0500, Eric W. Biederman wrote:
> Alexey Gladkov <email@example.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
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
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
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
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
> 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.
next prev parent reply other threads:[~2020-06-05 0:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 20:04 [PATCH 0/2] proc: use subset option to hide some top-level procfs entries Alexey Gladkov
2020-06-04 20:04 ` [PATCH 1/2] " Alexey Gladkov
2020-06-05 2:19 ` kernel test robot
2020-06-05 2:19 ` [PATCH] proc: fix boolreturn.cocci warnings kernel test robot
2020-06-04 20:04 ` [PATCH 2/2] docs: proc: update documentation about subset= parameter Alexey Gladkov
2020-06-04 20:33 ` [PATCH 0/2] proc: use subset option to hide some top-level procfs entries Eric W. Biederman
2020-06-04 21:32 ` Christian Brauner
2020-06-05 0:28 ` Alexey Gladkov
2020-06-05 0:08 ` Alexey Gladkov [this message]
2020-06-05 4:17 ` Eric W. Biederman
2020-06-05 14:47 ` Alexey Gladkov
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).