[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@xxxxxxxxxxxx> 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
