Re: Should mprotect(..., PROT_EXEC) be checked by IMA?

From: Igor Zhbanov <i.zhbanov@omprussia.ru>
To: Matthew Garrett <mjg59@google.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	Mimi Zohar <zohar@linux.ibm.com>,
	Kees Cook <keescook@chromium.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Paul Moore <paul@paul-moore.com>,
	John Johansen <john.johansen@canonical.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	Jann Horn <jannh@google.com>,
	linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
Date: Wed, 3 Apr 2019 20:31:23 +0300	[thread overview]
Message-ID: <bca4eb5b-2d76-5df8-6e63-573b3a057985@omprussia.ru> (raw)
In-Reply-To: <CACdnJusgwpcSxzwNEieqsa54_3cTYMEfuXpAeP0cW81TQ29E+w@mail.gmail.com>

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