Messages in this thread | | | From | David Hildenbrand <> | Subject | Re: [PATCH v18 0/9] mm: introduce memfd_secret system call to create "secret" memory areas | Date | Thu, 6 May 2021 19:24:43 +0200 |
| |
>>>> Is this intended to protect keys/etc after the attacker has >>>> gained the ability to run arbitrary kernel-mode code? If so, >>>> that seems optimistic, doesn't it? >>> >>> Not exactly: there are many types of kernel attack, but mostly the >>> attacker either manages to effect a privilege escalation to root or >>> gets the ability to run a ROP gadget. The object of this code is >>> to be completely secure against root trying to extract the secret >>> (some what similar to the lockdown idea), thus defeating privilege >>> escalation and to provide "sufficient" protection against ROP >>> gadget. >> >> What stops "root" from mapping /dev/mem and reading that memory? > > /dev/mem uses the direct map for the copy at least for read/write, so > it gets a fault in the same way root trying to use ptrace does. I > think we've protected mmap, but Mike would know that better than I. >
I'm more concerned about the mmap case -> remap_pfn_range(). Anybody going via the VMA shouldn't see the struct page, at least when vma_normal_page() is properly used; so you cannot detect secretmem memory mapped via /dev/mem reliably. At least that's my theory :)
[...]
>> Also, there is a way to still read that memory when root by >> >> 1. Having kdump active (which would often be the case, but maybe not >> to dump user pages ) >> 2. Triggering a kernel crash (easy via proc as root) >> 3. Waiting for the reboot after kump() created the dump and then >> reading the content from disk. > > Anything that can leave physical memory intact but boot to a kernel > where the missing direct map entry is restored could theoretically > extract the secret. However, it's not exactly going to be a stealthy > extraction ... > >> Or, as an attacker, load a custom kexec() kernel and read memory >> from the new environment. Of course, the latter two are advanced >> mechanisms, but they are possible when root. We might be able to >> mitigate, for example, by zeroing out secretmem pages before booting >> into the kexec kernel, if we care :) > > I think we could handle it by marking the region, yes, and a zero on > shutdown might be useful ... it would prevent all warm reboot type > attacks.
Right. But I guess when you're actually root, you can just write a kernel module to extract the information you need (unless we have signed modules, so it could be harder/impossible).
-- Thanks,
David / dhildenb
| |