> When it's actually calling mmap or mprotect, the process context is present, and the kernel can see if it actually has the permission before it makes the change
Consider that the kernel doesn't know who called mmap() or mprotect() though. mmap() goes into mmap@@GLIBC, which goes into syscall@@GLIBC, which enters the kernel at the syscall entry point plus the offset for mmap(). Same with mprotect().
The kernel isn't tracking code call paths (this is difficult, would be very slow, and can be spoofed); it's the entire process that's allowed to do it. If you say the JIT is allowed to call mprotect(PROT_WRITE|PROT_EXECUTE), and the JIT links with libxml2, then a bug in libxml2 will allow an attacker to mprotect(PROT_WRITE|PROT_EXECUTE) ONLY in the JIT process and not in any other program using libxml2.
I'm trying to think of a way to contextually control calls, but right now there's no mechanism and nothing I can prove secure. I will think about it.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds