Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     linux-integrity@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org,
        Igor Zhbanov <i.zhbanov@omprussia.ru>,
        Jordan Glover <Golden_Miller83@protonmail.ch>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Mimi Zohar <zohar@linux.ibm.com>
Subject: [PATCH 0/3] ima: addressing mmap/mprotect concerns
Date:   Mon,  6 May 2019 12:57:01 -0400
Message-Id: <1557161824-6623-1-git-send-email-zohar@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Igor Zhbanov's "Should mprotect(..., PROT_EXEC) be checked by IMA?"
thread raised concerns about IMA's handling of mmap/mprotect. [1]  The
kernel calls deny_write_access() to prevent a file already opened for
write from being executed and also prevents files being executed from
being opened for write.  For some reason this does not extend to files
being mmap'ed execute.  This is a known, well described problem.[2]
Jordan Glover commented that the proposed minor LSM "SARA" addresses
this issue.[3]

This patch set attempts to address some the IMA mmap/mprotect concerns
without locking the mmap'ed files.

Mimi

[1] https://lore.kernel.org/linux-integrity/cce2c4c7-5333-41c3-aeef-34d43e63acb0@omprussia.ru/
[2] ]https://pax.grsecurity.net/docs/mprotect.txt
[3] https://sara.smeso.it/en/latest/

Mimi Zohar (3):
  ima: verify mprotect change is consistent with mmap policy
  ima: prevent a file already mmap'ed write to be mmap'ed execute
  ima: prevent a file already mmap'ed read|execute to be mmap'ed write

 include/linux/ima.h               |  6 +++--
 security/integrity/ima/ima_main.c | 53 ++++++++++++++++++++++++++++++++++++---
 security/security.c               |  9 +++++--
 3 files changed, 61 insertions(+), 7 deletions(-)

-- 
2.7.5