On 19.03.2019 20:05, Mimi Zohar wrote:
Ok, so we can start there and modify the existing ima_file_mmap() to verify file signatures that are being mmap'ed read. The question will then become what to do with mprotect write and execute. And what would you do with the mprotect without a file descriptor? The mmap signature verification status is cached in the iint, based on the inode. I think whatever solution will need to be able to access this cached information.
Well, I think that IMA should check every executable page having a backing storage, i.e. when a page is mmapped from a file. So it will not be possible to store any new untrusted code on the disk. (Except of reading it into read-only page, then creating anonymous executable page and copying it there.) As for creating anonymous executable pages, yes, there is nothing to check. May be there should be some another LSM or prctl for that: whether some process should have anonymous executable pages at all. I think that since stack and data should be non-executable, normal apps should not have any anonymous executable pages at all. On 19.03.2019 20:07, Matthew Garrett wrote:
Remember that an application can also open a file read-only and then execute the code under an interpreter. If you have code that's deliberately trying to undermine IMA then it can do so - the goal is to use IMA to ensure that you have appropriate measurement or appraisal in order to avoid that in the first place.
As for scripts interpreters like bash, yes, it will not protect against it. But IMA can check e.g. all files read by root including non-executable ones. My point was about better protecting of shared libraries making life harder for exploits that are downloading extra code from external servers.
