[RFC PATCH] ima: verify mprotect change is consistent with mmap policy
Mimi Zohar
zohar at linux.ibm.com
Tue May 5 14:16:44 UTC 2020
Hi Jann,
On Tue, 2020-05-05 at 02:15 +0200, Jann Horn wrote:
> On Mon, May 4, 2020 at 11:18 PM Mimi Zohar <zohar at linux.ibm.com> wrote:
> > Files can be mmap'ed read/write and later changed to execute to circumvent
> > IMA's mmap appraise policy rules. Due to locking issues (mmap semaphore
> > would be taken prior to i_mutex), files can not be measured or appraised at
> > this point. Eliminate this integrity gap, by denying the mprotect
> > PROT_EXECUTE change, if an mmap appraise policy rule exists.
>
> Just keep in mind that there are other ways to create executable
> mappings containing controlled code; e.g. PROT_EXEC with
> MAP_ANONYMOUS, or writing to /proc/self/mem (which is a debugging API
> that works entirely without ever making the VMA writable - I had an
> old series to provide LSM hooks for that stuff at
> <https://lore.kernel.org/lkml/1478142286-18427-3-git-send-email-jann@thejh.net/>,
> but I guess I must have forgotten about it or something...).
Sure. These sound like memory attacks, which should be closed, but
are probably out of scope for IMA.
thanks,
Mimi
More information about the Linux-security-module-archive
mailing list