lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 May 2020 02:15:56 +0200 From: Jann Horn <jannh@...gle.com> To: Mimi Zohar <zohar@...ux.ibm.com> Cc: linux-integrity@...r.kernel.org, Stephen Smalley <stephen.smalley.work@...il.com>, Eric Biggers <ebiggers@...nel.org>, linux-security-module <linux-security-module@...r.kernel.org>, kernel list <linux-kernel@...r.kernel.org> Subject: Re: [RFC PATCH] ima: verify mprotect change is consistent with mmap policy On Mon, May 4, 2020 at 11:18 PM Mimi Zohar <zohar@...ux.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...).
Powered by blists - more mailing lists