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

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

[Mimi Zohar]

[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.

Mimi

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

[Jordan Glover]

On Friday, March 29, 2019 10:59 AM, Mimi Zohar <zohar@linux.ibm.com> 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.
>
> Mimi

There is already minor LSM in progress: https://sara.smeso.it/en/latest/

Jordan

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

[Stephen Smalley]

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?

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

[Igor Zhbanov]

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.

As for SELinux abilities I need to check what can it do and what can't. Don't
ready to comment on that now. Will check.

As for modular approach I think that having this feature separately is
beneficial for distros do not using SELinux.

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

[Matthew Garrett]

On Fri, Mar 29, 2019 at 5:50 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> 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.

Remember that many interpreted languages allow execution of code
provided to them on the command line (eg, python -c) and also grant
access to arbitrary syscalls, so there's still no guarantee that
you're only executing trusted code.

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

[Igor Zhbanov]

On 03.04.2019 1:31, Matthew Garrett wrote:
> On Fri, Mar 29, 2019 at 5:50 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> 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.
> 
> Remember that many interpreted languages allow execution of code
> provided to them on the command line (eg, python -c) and also grant
> access to arbitrary syscalls, so there's still no guarantee that
> you're only executing trusted code.

Yes. But in some installations you can get rid of interpreters at all or limit
the number of scripts they can open. For example you can require that all
scripts have to be signed.

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?

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

[Matthew Garrett]

On Wed, Apr 3, 2019 at 2:59 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>
> On 03.04.2019 1:31, Matthew Garrett wrote:
> > Remember that many interpreted languages allow execution of code
> > provided to them on the command line (eg, python -c) and also grant
> > access to arbitrary syscalls, so there's still no guarantee that
> > you're only executing trusted code.
>
> Yes. But in some installations you can get rid of interpreters at all or limit
> the number of scripts they can open. For example you can require that all
> scripts have to be signed.

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.

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

[Igor Zhbanov]

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.

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

[Matthew Garrett]

On Wed, Apr 3, 2019 at 10:31 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> I'm trying to reduce attacker's possibilities to inject any new unauthorized
> code. Currently it could be:

(snip)

> 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.

There's two possible cases here:

1) The application is legitimate but can be convinced to open and
execute malicious code. There should be no such applications that
download code from the internet and execute it directly, so this can
be prevented by requiring that files be signed (which has to be done
to protect against attackers just using an interpreted language
instead)
2) The application is actively malicious. In this case this approach
is insufficient - an actively malicious application can interpret code
rather than executing it directly. This can only be prevented by not
signing malicious applications.

When you talk about "staying below the radar" it implies that you're
talking about case 2, but the proposed solution is only a speed bump
rather than a blocker.

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

[Igor Zhbanov]

On 03.04.2019 21:19, Matthew Garrett wrote:
> On Wed, Apr 3, 2019 at 10:31 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> I'm trying to reduce attacker's possibilities to inject any new unauthorized
>> code. Currently it could be:
> 
> (snip)
> 
>> 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.
> 
> There's two possible cases here:
> 
> 1) The application is legitimate but can be convinced to open and
> execute malicious code. There should be no such applications that
> download code from the internet and execute it directly, so this can
> be prevented by requiring that files be signed (which has to be done
> to protect against attackers just using an interpreted language
> instead)
> 2) The application is actively malicious. In this case this approach
> is insufficient - an actively malicious application can interpret code
> rather than executing it directly. This can only be prevented by not
> signing malicious applications.
> 
> When you talk about "staying below the radar" it implies that you're
> talking about case 2, but the proposed solution is only a speed bump
> rather than a blocker.

But what about buffer/stack overflow? The application doesn't need to be
malicious. It could be just a web-browser or e-mail client processing
some evil file.

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

[Matthew Garrett]

On Wed, Apr 3, 2019 at 11:47 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> On 03.04.2019 21:19, Matthew Garrett wrote:
> > There's two possible cases here:
> >
> > 1) The application is legitimate but can be convinced to open and
> > execute malicious code. There should be no such applications that
> > download code from the internet and execute it directly, so this can
> > be prevented by requiring that files be signed (which has to be done
> > to protect against attackers just using an interpreted language
> > instead)
> > 2) The application is actively malicious. In this case this approach
> > is insufficient - an actively malicious application can interpret code
> > rather than executing it directly. This can only be prevented by not
> > signing malicious applications.
> >
> > When you talk about "staying below the radar" it implies that you're
> > talking about case 2, but the proposed solution is only a speed bump
> > rather than a blocker.
>
> But what about buffer/stack overflow? The application doesn't need to be
> malicious. It could be just a web-browser or e-mail client processing
> some evil file.

Executable pages shouldn't be writable?

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

[Igor Zhbanov]

On 03.04.2019 22:25, Matthew Garrett wrote:
> On Wed, Apr 3, 2019 at 11:47 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> On 03.04.2019 21:19, Matthew Garrett wrote:
>>> There's two possible cases here:
>>>
>>> 1) The application is legitimate but can be convinced to open and
>>> execute malicious code. There should be no such applications that
>>> download code from the internet and execute it directly, so this can
>>> be prevented by requiring that files be signed (which has to be done
>>> to protect against attackers just using an interpreted language
>>> instead)
>>> 2) The application is actively malicious. In this case this approach
>>> is insufficient - an actively malicious application can interpret code
>>> rather than executing it directly. This can only be prevented by not
>>> signing malicious applications.
>>>
>>> When you talk about "staying below the radar" it implies that you're
>>> talking about case 2, but the proposed solution is only a speed bump
>>> rather than a blocker.
>>
>> But what about buffer/stack overflow? The application doesn't need to be
>> malicious. It could be just a web-browser or e-mail client processing
>> some evil file.
> 
> Executable pages shouldn't be writable?

Shouldn't. But I think about following:

1) Small ROP part downloads bigger portion of code to RW page.
2) Then it switches it to RX page with mprotect.

And this bigger downloaded code could try to steal data or to probe for
another holes. I believe that it's very hard to implement big ROP exploit.
It's easier to implement it in parts: smaller one takes control and downloads
the bigger one.

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

[Mimi Zohar]

On Tue, 2019-04-02 at 15:31 -0700, Matthew Garrett wrote:
> On Fri, Mar 29, 2019 at 5:50 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> > 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.
> 
> Remember that many interpreted languages allow execution of code
> provided to them on the command line (eg, python -c) and also grant
> access to arbitrary syscalls, so there's still no guarantee that
> you're only executing trusted code.

Interpreters are a known concern, as Yves-Alexis Perez pointed out in
his LSS-2018 Europe talk[1].

Mimi

[1] https://events.linuxfoundation.org/wp-content/uploads/2017/12/Linu
x-Kernel-Security-Contributions-by-ANSSI-Yves-Alexis-Perez-ANSSI.pdf

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

[Perez Yves-Alexis]

Le 03/04/2019 à 14:11, Mimi Zohar a écrit :
> On Tue, 2019-04-02 at 15:31 -0700, Matthew Garrett wrote:
>> On Fri, Mar 29, 2019 at 5:50 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>>> 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.
>>
>> Remember that many interpreted languages allow execution of code
>> provided to them on the command line (eg, python -c) and also grant
>> access to arbitrary syscalls, so there's still no guarantee that
>> you're only executing trusted code.
>
> Interpreters are a known concern, as Yves-Alexis Perez pointed out in
> his LSS-2018 Europe talk[1].
>
> Mimi
>
> [1] https://events.linuxfoundation.org/wp-content/uploads/2017/12/Linu
> x-Kernel-Security-Contributions-by-ANSSI-Yves-Alexis-Perez-ANSSI.pdf
>
And Mickaël Salaün posted the O_MAYEXEC patch RFC back in December
(https://lore.kernel.org/lkml/20181212081712.32347-1-mic@digikod.net/)

Regards,
--
Yves-Alexis Perez
ANSSI/SDE/ST/LAM
Les données à caractère personnel recueillies et traitées dans le cadre de cet échange, le sont à seule fin d’exécution d’une relation professionnelle et s’opèrent dans cette seule finalité et pour la durée nécessaire à cette relation. Si vous souhaitez faire usage de vos droits de consultation, de rectification et de suppression de vos données, veuillez contacter contact.rgpd@sgdsn.gouv.fr. Si vous avez reçu ce message par erreur, nous vous remercions d’en informer l’expéditeur et de détruire le message. The personal data collected and processed during this exchange aims solely at completing a business relationship and is limited to the necessary duration of that relationship. If you wish to use your rights of consultation, rectification and deletion of your data, please contact: contact.rgpd@sgdsn.gouv.fr. If you have received this message in error, we thank you for informing the sender and destroying the message.

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

[Mimi Zohar]

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.

Mimi

Re: 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.

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

[Mimi Zohar]

On Wed, 2019-04-03 at 09:10 -0400, Stephen Smalley wrote:
> On 4/3/19 7:57 AM, Mimi Zohar wrote:

> > 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.

From a measurement perspective, this will at least measure the file,
but the call to ima_file_mmap() will verify the file signature against
the file, not what is currently in memory, right?

Mimi

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

[Stephen Smalley]

On 4/3/19 10:33 AM, Mimi Zohar wrote:
> On Wed, 2019-04-03 at 09:10 -0400, Stephen Smalley wrote:
>> On 4/3/19 7:57 AM, Mimi Zohar wrote:
> 
>>> 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.
> 
>  From a measurement perspective, this will at least measure the file,
> but the call to ima_file_mmap() will verify the file signature against
> the file, not what is currently in memory, right?

Yes, but you can use SELinux to prevent that (don't allow execmem or 
execmod permissions for that domain).

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

[Mimi Zohar]

On Wed, 2019-04-03 at 10:33 -0400, Stephen Smalley wrote:
> On 4/3/19 10:33 AM, Mimi Zohar wrote:
> > On Wed, 2019-04-03 at 09:10 -0400, Stephen Smalley wrote:
> >> On 4/3/19 7:57 AM, Mimi Zohar wrote:
> > 
> >>> 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.
> > 
> >  From a measurement perspective, this will at least measure the file,
> > but the call to ima_file_mmap() will verify the file signature against
> > the file, not what is currently in memory, right?
> 
> Yes, but you can use SELinux to prevent that (don't allow execmem or 
> execmod permissions for that domain).

Ok, let's start with at least adding the ima_file_mmap() call as you
suggested.  For LSMs which don't have this capability, they might need
to be stacked with a minor LSM such as S.A.R.A, once it is upstreamed,
or similar.

Mimi