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:
On Thu, May 06, 2021 at 08:26:41AM -0700, James Bottomley wrote:
[...]
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:
- 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).
- 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.