On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote:
On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote:
- Kees because this is related to W^X memfd and security.
On Fri, Jan 3, 2025 at 7:14 AM Jann Horn jannh@google.com wrote:
On Fri, Dec 6, 2024 at 7:19 PM Lorenzo Stoakes lorenzo.stoakes@oracle.com wrote:
On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote:
if (is_exec_sealed(seals)) {Are we intentionally disallowing a MAP_PRIVATE memfd's mapping's execution? I've not tested this scenario so don't know if we somehow disallow this in another way but note on write checks we only care about shared mappings.
I mean one could argue that a MAP_PRIVATE situation is the same as copying the data into an anon buffer and doing what you want with it, here you could argue the same...
So probably we should only care about VM_SHARED?
FWIW I think it doesn't make sense to distinguish between shared/private mappings here - in the scenario described in the cover letter, it wouldn't matter that much to an attacker whether the mapping is shared or private (as long as the VMA contents haven't been CoWed already).
+1 on this. The concept of blocking this for only shared mapping is questionable.
Right -- why does sharedness matter? It seems more robust to me to not create a corner case but rather apply the flag/behavior universally?
I'm struggling to understand what you are protecting against, if I can receive a buffer '-not executable-'. But then copy it into another buffer I mapped, and execute it?
I mean am I missing something? It's very possible :)
The cost is complexity. And the difference between mappings which are shared and those which are private and moreso MAP_PRIVATE of an fd are actually quite a lot internally (go look at anon_vma code if you have the great benefit of not yet doing so to see the deepest, darkest, 9th circle of complexity hell :>).
Again, I may be missing the point here or misunderstanding the apparent attack vector, but this is where I'm coming from.
-- Kees Cook