lkml.org 
[lkml]   [2022]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC 0/4] mm, arm64: In-kernel support for memory-deny-write-execute (MDWE)
On Thu, Apr 21, 2022 at 09:42:23AM -0700, Kees Cook wrote:
> On Thu, Apr 21, 2022 at 04:35:15PM +0100, Catalin Marinas wrote:
> > Do we want the "was PROT_WRITE" or we just reject mprotect(PROT_EXEC) if
> > the vma is not already PROT_EXEC? The latter is closer to the current
> > systemd approach. The former allows an mprotect(PROT_EXEC) if the
> > mapping was PROT_READ only for example.
> >
> > I'd drop the "was PROT_WRITE" for now if the aim is a drop-in
> > replacement for BPF MDWE.
>
> I think "was PROT_WRITE" is an important part of the defense that
> couldn't be done with a simple seccomp filter (which is why the filter
> ended up being a problem in the first place).

I would say "was PROT_WRITE" is slightly more relaxed than "is not
already PROT_EXEC". The seccomp filter can't do "is not already
PROT_EXEC" either since it only checks the mprotect() arguments, not the
current vma flags.

So we have (with sub-cases):

1. Current BPF filter:

a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails

b) mmap(PROT_READ|PROT_EXEC);
mprotect(PROT_READ|PROT_EXEC|PROT_BTI); // fails

2. "is not already PROT_EXEC":

a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails

b) mmap(PROT_READ|PROT_EXEC);
mmap(PROT_READ|PROT_EXEC|PROT_BTI); // passes

c) mmap(PROT_READ);
mprotect(PROT_READ|PROT_EXEC); // fails

3. "is or was not PROT_WRITE":

a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails

b) mmap(PROT_READ|PROT_EXEC);
mmap(PROT_READ|PROT_EXEC|PROT_BTI); // passes

c) mmap(PROT_READ);
mprotect(PROT_READ|PROT_EXEC); // passes

d) mmap(PROT_READ|PROT_WRITE);
mprotect(PROT_READ);
mprotect(PROT_READ|PROT_EXEC); // fails (was write)

The current seccomp filter is the strictest. If we go for (2), it allows
PROT_BTI as in 2.b but prevents 2.c (as would the current seccomp
filter). (3) relaxes 2.c as in 3.c while still preventing 3.d. Both (1)
and (2) prevent 3.d by simply rejecting mprotect(PROT_EXEC).

If we don't care about 3.c, we might as well go for (2). I don't mind,
already went for (3) in this series. I think either of them would not be
a regression on MDWE, unless there is some test that attempts 3.c and
expects it to fail.

--
Catalin

\
 
 \ /
  Last update: 2022-04-21 19:25    [W:0.161 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site