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

[Stephen Smalley]

On 4/3/19 7:57 AM, Mimi Zohar wrote:
> On Fri, 2019-03-29 at 15:50 +0300, Igor Zhbanov wrote:
>> On 29.03.2019 15:28, Stephen Smalley wrote:
>>> On 3/29/19 6:59 AM, Mimi Zohar wrote:
>>>> [Cc'ing the LSM mailing list and others]
>>>>
>>>> On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
>>>>> Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
>>>>
>>>>>> I just came across the grsecurity article on mprotect.[1]
>>>>>>    Has anyone looked at it? Would it make sense to make it a minor LSM?
>>>>>>
>>>>>> [1]https://pax.grsecurity.net/docs/mprotect.txt
>>>>>
>>>>> Interesting article. It is almost exactly of what I wanted to be
>>>>> implemented.
>>>>>
>>>>> If this minor LSM would be stackable to allow combining with e.g. SELinux
>>>>> then why not.
>>>>
>>>> Stacking shouldn't be a problem.  Other LSMs are already on the
>>>> mprotect hook.  Let's hear what others think.
>>>
>>> SELinux already provides a set of controls over executable mappings;
>>> see selinux_mmap_file and selinux_file_mprotect. Other major security
>>> modules may do likewise but I can't speak to that. Is there some gap
>>> you are trying to address that isn't already covered, or are you just
>>> trying to provide such restrictions without requiring one of the
>>> major modules?
>>
>> I want to be sure that no unsigned code page could be executed. So exploits
>> could only be of ROP kind and not being able to download any extra code
>> from their servers. That's why I found that disabling of anonymous executable
>> pages could be useful for that (as well as disabling of making executable
>> pages writable to modify already mapped code). In conjunction with IMA it
>> should guarantee that no untrusted code could be executed.
> 
> Let's separate the different types of attacks.  From an IMA
> perspective, memory attacks are out of scope.  That leaves mmap'ed
> files, possibly just mmap'ed shared files.  Currently IMA can be
> configured to verify a file's integrity, based on signatures, being
> mmap'ed execute.  Assuming that not all files opened require a file
> signature, a file could be mmap'ed read/write and later changed to
> execute to circumvent the mmap'ed execute signature requirement.  If
> the existing LSMs are able to prevent this sort of attack, we could
> just document this requirement.

I guess I don't understand why IMA isn't already being called from 
security_file_mprotect(). security_file_mprotect() could just call 
ima_file_mmap(vma->vm_file, prot) if all of the security hooks pass.

SELinux can be used to prevent unauthorized mprotect PROT_EXEC but it 
won't perform a measurement of the file if it is allowed by policy.