archive mirror
 help / color / mirror / Atom feed
From: Alexey Gladkov <>
To: "Eric W. Biederman" <>
Cc: LKML <>,
	Linux FS Devel <>,
	Alexander Viro <>,
	Alexey Dobriyan <>,
	Andy Lutomirski <>,
	Kees Cook <>,
	Linux Containers <>
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)
In-Reply-To: <>

On Thu, Jun 04, 2020 at 03:33:25PM -0500, Eric W. Biederman wrote:
> Alexey Gladkov <> writes:
> > Greetings!
> >
> > Preface
> > -------
> > This patch set can be applied over:
> >
> > 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

  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

Reply instructions:

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 \
    --in-reply-to=20200605000838.huaeqvgpvqkyg3wh@comp-core-i7-2640m-0182e6 \ \ \ \ \ \ \ \ \ \

* 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).