public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexey Gladkov <legion@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>,
	viro@zeniv.linux.org.uk, ebiederm@xmission.com,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, stephen.s.brennan@oracle.com,
	cyphar@cyphar.com
Subject: Re: [PATCH v2] proc: "mount -o lookup=" support
Date: Wed, 19 Jan 2022 18:15:22 +0100	[thread overview]
Message-ID: <20220119171522.pxmkbt5eu3rs5yik@example.org> (raw)
In-Reply-To: <20220119162423.eqbyefywhtzm22tr@wittgenstein>

On Wed, Jan 19, 2022 at 05:24:23PM +0100, Christian Brauner wrote:
> On Wed, Jan 19, 2022 at 06:48:03PM +0300, Alexey Dobriyan wrote:
> > From 61376c85daab50afb343ce50b5a97e562bc1c8d3 Mon Sep 17 00:00:00 2001
> > From: Alexey Dobriyan <adobriyan@gmail.com>
> > Date: Mon, 22 Nov 2021 20:41:06 +0300
> > Subject: [PATCH 1/1] proc: "mount -o lookup=..." support
> > 
> > Docker implements MaskedPaths configuration option
> > 
> > 	https://github.com/estesp/docker/blob/9c15e82f19b0ad3c5fe8617a8ec2dddc6639f40a/oci/defaults.go#L97
> > 
> > to disable certain /proc files. It overmounts them with /dev/null.
> > 
> > Implement proper mount option which selectively disables lookup/readdir
> > in the top level /proc directory so that MaskedPaths doesn't need
> > to be updated as time goes on.
> 
> I might've missed this when this was sent the last time so maybe it was
> clearly explained in an earlier thread: What's the reason this needs to
> live in the kernel?
> 
> The MaskedPaths entry is optional so runtimes aren't required to block
> anything by default and this mostly makes sense for workloads that run
> privileged.
> 
> In addition MaskedPaths is a generic option which allows to hide any
> existing path, not just proc. Even in the very docker-specific defaults
> /sys/firmware is covered.
> 
> I do see clear value in the subset= and hidepid= options. They are
> generally useful independent of opinionated container workloads. I don't
> see the same for lookup=.
> 
> An alternative I find more sensible is to add a new value for subset=
> that hides anything(?) that only global root should have read/write
> access too.

Or we can allow to change permissions in the procfs only in the direction
of decreasing (if some file has 644 then allow to set 640 or 600). In this
case, we will not need to constantly check the whitelist.

-- 
Rgrds, legion


  reply	other threads:[~2022-01-19 17:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-19 15:48 [PATCH v2] proc: "mount -o lookup=" support Alexey Dobriyan
2022-01-19 15:57 ` Alexey Dobriyan
2022-01-19 16:24 ` Christian Brauner
2022-01-19 17:15   ` Alexey Gladkov [this message]
2022-01-19 17:31     ` Christian Brauner
2022-01-19 18:30       ` Alexey Gladkov
2022-01-20 12:23   ` Alexey Dobriyan
2022-01-20 14:37     ` Christian Brauner
2022-01-20 12:32   ` Alexey Dobriyan
2022-01-19 17:04 ` Alexey Gladkov
2022-01-20 12:26   ` Alexey Dobriyan

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220119171522.pxmkbt5eu3rs5yik@example.org \
    --to=legion@kernel.org \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stephen.s.brennan@oracle.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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