[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi9qsy-bX65ev8jgDzGM+uTk=Vbix32F8SLfUWegajT+w@mail.gmail.com>
Date: Wed, 17 Jul 2024 17:04:27 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: Adrian Ratiu <adrian.ratiu@...labora.com>, linux-fsdevel@...r.kernel.org,
linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org, kernel@...labora.com, gbiv@...gle.com,
inglorion@...gle.com, ajordanr@...gle.com,
Doug Anderson <dianders@...omium.org>, Jeff Xu <jeffxu@...gle.com>, Jann Horn <jannh@...gle.com>,
Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH] proc: add config to block FOLL_FORCE in mem writes
On Wed, 17 Jul 2024 at 15:24, Kees Cook <kees@...nel.org> wrote:
>
> > In particular, this patch would make it easy to make that
> > SECURITY_PROC_MEM_RESTRICT_FOLL_FORCE config option be a "choice"
> > where you pick "never, ptrace, always" by just changing the rules in
> > proc_is_ptracing().
>
> So the original patch could be reduced to just the single tristate option
> instead of 3 tristates? I think that would be a decent middle ground,
> and IIUC, will still provide the coverage Chrome OS is looking for[1].
So here's what I kind of think might be ok.
ENTIRELY UNTESTED! This is more of a "look, something like this,
perhaps" patch than a real one.
If somebody tests this, and it is ok for Chrome OS, you can consider
this signed-off-on, but only with actual testing. I might have gotten
something hroribly wrong.
Linus
View attachment "patch.diff" of type "text/x-patch" (2554 bytes)
Powered by blists - more mailing lists