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

[Igor Zhbanov <i.zhbanov@omprussia.ru>]

On 20.03.2019 20:23, Matthew Garrett wrote:
> On Wed, Mar 20, 2019 at 1:11 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> 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?

Well, may be it would be enough to:
1) Verify with IMA every file root processes read,
2) Use seccomp to forbid mprotect(..., PROT_EXEC) for 99% of processes,
    so they would have to use normal mmap(..., PROT_EXEC, ...) to load the
    code.

P.S. #2 should also protect against patching already mapped executable pages
because they are typically mapped read-only, so one would use
mprotect(..., PROT_READ | PROT_WRITE | PROT_EXEC) to enable write access
to it. So with #2 it wouldn't even be possible to reuse already mapped
pages nor to create new.

May be #2 could be implemented as a separate thing to avoid writing eBPF
seccomp filters to check mprotect() argument for rised PROT_EXEC flag.