On Thu, May 06, 2021 at 11:47:47AM -0700, James Bottomley wrote:

On Thu, 2021-05-06 at 10:33 -0700, Kees Cook wrote:

quoted

On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:

[...]

quoted

quoted

quoted

I think that a very complete description of the threats which
this feature addresses would be helpful.  

It's designed to protect against three different threats:

   1. Detection of user secret memory mismanagement

I would say "cross-process secret userspace memory exposures" (via a
number of common interfaces by blocking it at the GUP level).

quoted

   2. significant protection against privilege escalation

I don't see how this series protects against privilege escalation.
(It protects against exfiltration.) Maybe you mean include this in
the first bullet point (i.e. "cross-process secret userspace memory
exposures, even in the face of privileged processes")?

It doesn't prevent privilege escalation from happening in the first
place, but once the escalation has happened it protects against
exfiltration by the newly minted root attacker.

So, after thinking a bit more about this, I don't think there is
protection here against privileged execution. This feature kind of helps
against cross-process read/write attempts, but it doesn't help with
sufficiently privileged (i.e. ptraced) execution, since we can just ask
the process itself to do the reading:

$ gdb ./memfd_secret
...
ready: 0x7ffff7ffb000
Breakpoint 1, ...
(gdb) compile code unsigned long addr = 0x7ffff7ffb000UL; printf("%016lx\n", *((unsigned long *)addr));
55555555555555555

And since process_vm_readv() requires PTRACE_ATTACH, there's very little
difference in effort between process_vm_readv() and the above.

So, what other paths through GUP exist that aren't covered by
PTRACE_ATTACH? And if none, then should this actually just be done by
setting the process undumpable? (This is already what things like gnupg
do.)

So, the user-space side of this doesn't seem to really help. The kernel
side protection is interesting for kernel read/write flaws, though, in
the sense that the process is likely not being attacked from "current",
so a kernel-side attack would need to either walk the page tables and
create new ones, or spawn a new userspace process to do the ptracing.

So, while I like the idea of this stuff, and I see how it provides
certain coverages, I'm curious to learn more about the threat model to
make sure it's actually providing meaningful hurdles to attacks.

-- 
Kees Cook