Re: [PATCH] proc: add config to block FOLL_FORCE in mem writes

[Kees Cook <kees@kernel.org>]

On Wed, Jul 17, 2024 at 11:16:56AM -0700, Linus Torvalds wrote:
> On Wed, 17 Jul 2024 at 10:23, Kees Cook <kees@kernel.org> wrote:
> >
> > For this to be available for general distros, I still want to have a
> > bootparam to control this, otherwise this mitigation will never see much
> > testing as most kernel deployments don't build their own kernels. A
> > simple __ro_after_init variable can be used.
> 
> Oh, btw, I looked at the FOLL_FORCE back in 2017 when we did this:
> 
>     8ee74a91ac30 ("proc: try to remove use of FOLL_FORCE entirely")
> 
> and then we had to undo that with
> 
>     f511c0b17b08 (""Yes, people use FOLL_FORCE ;)"")
> 
> but at the time I also had an experimental patch that worked for me,
> but I seem to have only sent that out in private to the people
> involved with the original issue.
> 
> And then that whole discussion petered out, and nothing happened.
> 
> But maybe we can try again.
> 
> In particular, while people piped up about other uses (see the quotes
> in that commit f511c0b17b08) they were fairly rare and specialized.
> 
> The one *common* use was gdb.
> 
> But my old diff from years ago mostly still applies, so I resurrected it.
> 
> It basically restricts FOLL_FORCE to just ptracers.
> 
> That's *not* good for some of the people that piped up back when (eg
> Julia JIT), but it might be a more palatable halfway state.
> 
> 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].

-Kees

[1] https://lore.kernel.org/lkml/CABi2SkWDwAU2ARyMVTeCqFeOXyQZn3hbkdWv-1OzzgG=MNoU8Q@mail.gmail.com/

-- 
Kees Cook