On Thu, Mar 21, 2019 at 4:22 AM Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > [Cc'ing Jann Horn, who brought this topic up last year.] > > On Wed, 2019-03-20 at 10:23 -0700, Matthew Garrett wrote: > > > > 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. The question is whether it really makes it more difficult for attackers :) If we block one avenue but leave another open, we haven't won that much - we've added complexity to the kernel, but the attackers are still able to inject code. Fundamentally, I can't see any way we can prevent all avenues of code injection - instead I've interpreted IMA appraisal as a statement that we believe the signed binary won't deliberately attempt to circumvent our security model, and then the problem goes away.
