Re: Should mprotect(..., PROT_EXEC) be checked by IMA?

[Mimi Zohar <zohar@linux.ibm.com>]

[Cc'ing Jann Horn, who brought this topic up last year.]

On Wed, 2019-03-20 at 10:23 -0700, Matthew Garrett wrote:
> On Wed, Mar 20, 2019 at 1:11 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:

<snip>

> > My point was about better protecting of shared libraries making life harder
> > for exploits that are downloading extra code from external servers.
> 
> Like you said, they can implement this by copying the code from
> read-only pages to separate executable pages. It does make it harder,
> but not to a huge degree - anything that's mprotect()ing file-backed
> pages to PROT_EXEC later is presumably doing so to avoid IMA, and
> making this change will just encourage them to add further
> workarounds. Since this is a fight we literally can't win, what's the
> benefit?

Really, Matthew?  Such gloomy thoughts coming from someone advocating
the "lockdown" patch set and extending IMA/EVM.  Part of our job
description as Linux kernel security/integrity developers is exactly
that - to make it more difficult for attackers, by hardening the
system and closing one measurement/appraisal gap at a time.

Igor, as for shared libraries:

1. Extend ima_file_mmap() to permit, based on policy, verifying file
signatures for files being mmap'ed read and preventing validly signed
files from being mmap'ed write.

2. Define an IMA mprotect hook that permits, based on policy,
preventing memory having validly signed backing storage from setting
the memory region to write, but allow execute.

(This will require access to the IMA mmap signature verification
status cached in the "iint".)

Mimi