Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Kees Cook <keescook@chromium.org>
Cc: Julius Hemanth Pitti <jpitti@cisco.com>,
	mingo@elte.hu, akpm@linux-foundation.org, yzaikin@google.com,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@zeniv.linux.org.uk, xe-linux-external@cisco.com,
	jannh@google.com
Subject: Re: [PATCH] proc/sysctl: make protected_* world readable
Date: Wed, 29 Jul 2020 00:03:32 +0000	[thread overview]
Message-ID: <20200729000332.GJ4332@42.do-not-panic.com> (raw)
In-Reply-To: <202007092122.782EE053@keescook>

On Thu, Jul 09, 2020 at 09:31:37PM -0700, Kees Cook wrote:
> On Thu, Jul 09, 2020 at 04:51:15PM -0700, Julius Hemanth Pitti wrote:
> > protected_* files have 600 permissions which prevents
> > non-superuser from reading them.
> > 
> > Container like "AWS greengrass" refuse to launch unless
> > protected_hardlinks and protected_symlinks are set. When
> > containers like these run with "userns-remap" or "--user"
> > mapping container's root to non-superuser on host, they
> > fail to run due to denied read access to these files.
> > 
> > As these protections are hardly a secret, and do not
> > possess any security risk, making them world readable.
> > 
> > Though above greengrass usecase needs read access to
> > only protected_hardlinks and protected_symlinks files,
> > setting all other protected_* files to 644 to keep
> > consistency.
> > 
> > Fixes: 800179c9b8a1 ("fs: add link restrictions")
> > Signed-off-by: Julius Hemanth Pitti <jpitti@cisco.com>
> 
> Acked-by: Kees Cook <keescook@chromium.org>
> 
> I had originally proposed it as 0644, but Ingo asked that it have
> a more conservative default value[1]. I figured that given the settings
> can be discovered easily, it's not worth much. And if there are legit
> cases where things are improved, I don't have a problem switching this
> back.

If we're going to to do this, can we please document why these are
"protected" then?

  Luis

> 
> Ingo, any thoughts on this now, 8 years later in the age of containers?
> :)
> 
> (One devil's advocate question: as a workaround, you are able to just
> change those files to 0644 after mounting /proc, yes? But regardless,
> why get in people's way for no justifiable reason.)
> 
> -Kees
> 
> [1] https://lore.kernel.org/lkml/20120105091704.GB3249@elte.hu/
> 
> -- 
> Kees Cook

      reply	other threads:[~2020-07-29  0:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 23:51 Julius Hemanth Pitti
2020-07-10  4:31 ` Kees Cook
2020-07-29  0:03   ` Luis Chamberlain [this message]

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=20200729000332.GJ4332@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=jpitti@cisco.com \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xe-linux-external@cisco.com \
    --cc=yzaikin@google.com \
    --subject='Re: [PATCH] proc/sysctl: make protected_* world readable' \
    /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

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