Should mprotect(..., PROT_EXEC) be checked by IMA?
i.zhbanov at omprussia.ru
Wed Apr 3 17:31:23 UTC 2019
On 03.04.2019 19:58, Matthew Garrett wrote:
> On Wed, Apr 3, 2019 at 2:59 AM Igor Zhbanov <i.zhbanov at omprussia.ru> wrote:
> No, that's my point - if you're able to pass code directly to the
> interpreter then you're not protected by file signatures. python -c
> 'print("hello")' will execute without the user-provided code touching
>> And having this feature as a per-process you could still limit the attack
>> surface by restricting e.g. network services as they are constantly attacked.
>> So are you saying that this feature doesn't worth to make it?
> I'm saying that before adding more security code you should describe
> the attack that you're actually trying to prevent. What you're doing
> prevents applications from opening a file read-only and then
> mprotect()ing it to being executable without IMA noticing, but what
> attack are you actually protecting against as a result? You block one
> avenue of obtaining code execution that isn't measured by IMA, but
> there are many more. Most (but not all) are blocked by requiring that
> all files be signed, but if all files are signed we don't need to
> change the behaviour here - opening the file read-only will be enough
> to trigger an appraisal.
I'm trying to reduce attacker's possibilities to inject any new unauthorized
code. Currently it could be:
1) Downloaded binaries (on disk) which is validated by IMA,
2) Downloaded scripts (which need some combined approach like removing
unneeded interpreters and checking the they are open and disabling passing
the script as command line argument),
3) Return-Oriented-Programming exploits. Compiler support for validating
return addresses is needed.
4) Anonymous executable pages (either new or existing changing to writable).
^ This is what I'm talking about. Because it's relatively easy to create
anonymous executable page to stay below the radar. Because even if you
enable signature checking for all opened files it would be possible to
simply download the code and execute it directly from the anonymous pages.
By closing one by one these possibilities one can be (relatively) sure that
only trusted code and scripts could be executed.
More information about the Linux-security-module-archive