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