On 03.04.2019 19:58, Matthew Garrett wrote:
On Wed, Apr 3, 2019 at 2:59 AM Igor Zhbanov <i.zhbanov@xxxxxxxxxxxx> 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
IMA.
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.
