From: Kees Cook <keescook@chromium.org>
To: Adrian Ratiu <adrian.ratiu@collabora.com>
Cc: linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
linux-doc@vger.kernel.org, kernel@collabora.com, gbiv@google.com,
ryanbeltran@google.com, inglorion@google.com,
ajordanr@google.com, jorgelo@chromium.org,
Guenter Roeck <groeck@chromium.org>,
Doug Anderson <dianders@chromium.org>,
Jann Horn <jannh@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Christian Brauner <brauner@kernel.org>
Subject: Re: [PATCH v3 2/2] proc: add Kconfigs to restrict /proc/pid/mem access
Date: Fri, 26 Apr 2024 16:16:34 -0700 [thread overview]
Message-ID: <202404261611.958FEB4@keescook> (raw)
In-Reply-To: <20240409175750.206445-2-adrian.ratiu@collabora.com>
On Tue, Apr 09, 2024 at 08:57:50PM +0300, Adrian Ratiu wrote:
> Some systems might have difficulty changing their bootloaders
> to enable the newly added restrict_proc_mem* params, for e.g.
> remote embedded doing OTA updates, so this provides a set of
> Kconfigs to set /proc/pid/mem restrictions at build-time.
>
> The boot params take precedence over the Kconfig values. This
> can be reversed, but doing it this way I think makes sense.
>
> Another idea is to have a global bool Kconfig which can enable
> or disable this mechanism in its entirety, however it does not
> seem necessary since all three knobs default to off, the branch
> logic overhead is rather minimal and I assume most of systems
> will want to restrict at least the use of FOLL_FORCE.
>
> Cc: Guenter Roeck <groeck@chromium.org>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Jann Horn <jannh@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Randy Dunlap <rdunlap@infradead.org>
> Cc: Christian Brauner <brauner@kernel.org>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> fs/proc/base.c | 33 +++++++++++++++++++++++++++++++++
> security/Kconfig | 42 ++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 75 insertions(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c733836c42a65..e8ee848fc4a98 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -889,6 +889,17 @@ static int __mem_open_check_access_restriction(struct file *file)
> !__mem_open_current_is_ptracer(file))
> return -EACCES;
>
> +#ifdef CONFIG_SECURITY_PROC_MEM_WRITE_RESTRICT
No, please. :)
Just use use the _MAYBE/_maybe variants of the static branch DECLAREs and
branches, and make Kconfigs for:
CONFIG_PROC_MEM_RESTRICT_READ_DEFAULT
CONFIG_PROC_MEM_RESTRICT_WRITE_DEFAULT
CONFIG_PROC_MEM_RESTRICT_FOLL_FORCE_DEFAULT
Like:
DECLARE_STATIC_KEY_MAYBE(CONFIG_PROC_MEM_RESTRICT_READ_DEFAULT, proc_mem_restrict_read);
and then later:
if (static_branch_maybe(CONFIG_PROC_MEM_RESTRICT_READ_DEFAULT,
&proc_mem_restrict_read))
...
Then all builds of the kernel will have it available, but system
builders who want it enabled by default will get a slightly more
optimized "if".
-Kees
--
Kees Cook
next prev parent reply other threads:[~2024-04-26 23:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-09 17:57 [PATCH v3 1/2] proc: restrict /proc/pid/mem access via param knobs Adrian Ratiu
2024-04-09 17:57 ` [PATCH v3 2/2] proc: add Kconfigs to restrict /proc/pid/mem access Adrian Ratiu
2024-04-26 23:16 ` Kees Cook [this message]
2024-04-26 23:10 ` [PATCH v3 1/2] proc: restrict /proc/pid/mem access via param knobs Kees Cook
2024-05-03 9:57 ` Christian Brauner
2024-05-13 23:50 ` Kees Cook
2024-05-15 11:15 ` Adrian Ratiu
2024-05-15 11:13 ` Adrian Ratiu
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=202404261611.958FEB4@keescook \
--to=keescook@chromium.org \
--cc=adrian.ratiu@collabora.com \
--cc=ajordanr@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=dianders@chromium.org \
--cc=gbiv@google.com \
--cc=groeck@chromium.org \
--cc=inglorion@google.com \
--cc=jannh@google.com \
--cc=jorgelo@chromium.org \
--cc=kernel@collabora.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=ryanbeltran@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.