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
prev parent 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 [PATCH] proc/sysctl: make protected_* world readable 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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.