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

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

[Igor Zhbanov]

Hello!

I've found that IMA checks for executable mmap()s but not for the combination
of mmap(..., PROT_READ, ...) + mprotect(..., PROT_EXEC).

So it looks like is possible to load arbitrary executable code by rewriting
dlopen() and dlsym() functions to map all ELF segments read-only first then
making them executable with mprotect().

So should security_file_mprotect() be changed similarly
to security_mmap_file() to call IMA security hook?

Thanks.

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

[Mimi Zohar]

On Mon, 2019-03-18 at 18:18 +0300, Igor Zhbanov wrote:
> Hello!
> 
> I've found that IMA checks for executable mmap()s but not for the combination
> of mmap(..., PROT_READ, ...) + mprotect(..., PROT_EXEC).
> 
> So it looks like is possible to load arbitrary executable code by rewriting
> dlopen() and dlsym() functions to map all ELF segments read-only first then
> making them executable with mprotect().
> 
> So should security_file_mprotect() be changed similarly
> to security_mmap_file() to call IMA security hook?

How?  security_mmap_file() is passed a file descriptor and the
signature, stored as an xattr, can be verified.

Mimi

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

[Igor Zhbanov]

Hi Mimi,

I guess similar to SELinux function:
---8<------------------------------------------------------------------------
static int selinux_file_mprotect(struct vm_area_struct *vma,
                                  unsigned long reqprot,
                                  unsigned long prot)
{
         const struct cred *cred = current_cred();
         u32 sid = cred_sid(cred);

         if (selinux_state.checkreqprot)
                 prot = reqprot;

         if (default_noexec &&
             (prot & PROT_EXEC) && !(vma->vm_flags & VM_EXEC)) {
                 int rc = 0;
                 if (vma->vm_start >= vma->vm_mm->start_brk &&
                     vma->vm_end <= vma->vm_mm->brk) {
                         rc = avc_has_perm(&selinux_state,
                                           sid, sid, SECCLASS_PROCESS,
                                           PROCESS__EXECHEAP, NULL);
                 } else if (!vma->vm_file &&
                            ((vma->vm_start <= vma->vm_mm->start_stack &&
                              vma->vm_end >= vma->vm_mm->start_stack) ||
                             vma_is_stack_for_current(vma))) {
                         rc = avc_has_perm(&selinux_state,
                                           sid, sid, SECCLASS_PROCESS,
                                           PROCESS__EXECSTACK, NULL);
                 } else if (vma->vm_file && vma->anon_vma) {
                         /*
                          * We are making executable a file mapping that has
                          * had some COW done. Since pages might have been
                          * written, check ability to execute the possibly
                          * modified content.  This typically should only
                          * occur for text relocations.
                          */
                         rc = file_has_perm(cred, vma->vm_file, FILE__EXECMOD);
                 }
                 if (rc)
                         return rc;
         }

         return file_map_prot_check(vma->vm_file, prot, vma->vm_flags&VM_SHARED);
}
---8<------------------------------------------------------------------------

The structure vm_area_struct has a pointer vm_file pointing to mapped file
so it could be used what file's xattrs to check.

Thanks.

On 19.03.2019 0:48, Mimi Zohar wrote:
> On Mon, 2019-03-18 at 18:18 +0300, Igor Zhbanov wrote:
>> Hello!
>>
>> I've found that IMA checks for executable mmap()s but not for the
>> combination of mmap(..., PROT_READ, ...) + mprotect(..., PROT_EXEC).
>>
>> So it looks like is possible to load arbitrary executable code
>> by rewriting dlopen() and dlsym() functions to map all ELF segments
>> read-only first then making them executable with mprotect().
>>
>> So should security_file_mprotect() be changed similarly
>> to security_mmap_file() to call IMA security hook?
> 
> How?  security_mmap_file() is passed a file descriptor and the signature,
> stored as an xattr, can be verified.
> 
> Mimi

-- 
Игорь Жбанов
зам. тех. директора по технологиям
ООО «Открытая мобильная платформа»
Тел.: +7 495 269-07-79, доб. 606
Моб.: +7 903 001-98-55
E-mail: i.zhbanov@omprussia.ru

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

[Mimi Zohar]

On Tue, 2019-03-19 at 10:50 +0300, Igor Zhbanov wrote:
> Hi Mimi,
> 
> I guess similar to SELinux function:
[snip]

Remember IMA relies on LSMs for mandatory access control(MAC).  IMA
measures, audits, and enforces file integrity.

> 
> The structure vm_area_struct has a pointer vm_file pointing to mapped file
> so it could be used what file's xattrs to check.

That's fine for when there is a file descriptor, but the file
descriptor could have been closed.  (Refer to the mmap manpage.)

Mimi

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

[Igor Zhbanov]

On 19.03.2019 14:22, Mimi Zohar wrote:
> On Tue, 2019-03-19 at 10:50 +0300, Igor Zhbanov wrote:
>> Hi Mimi,
>>
>> I guess similar to SELinux function:
> [snip]
> 
> Remember IMA relies on LSMs for mandatory access control(MAC).  IMA
> measures, audits, and enforces file integrity.

Yes. But LSM will not check integrity of the file mmaped for read. Nor does
IMA.

>> The structure vm_area_struct has a pointer vm_file pointing to mapped file
>> so it could be used what file's xattrs to check.
> 
> That's fine for when there is a file descriptor, but the file
> descriptor could have been closed.  (Refer to the mmap manpage.)

Can it be checked?

I think that checking the integrity at least in the case when the file is
still open is better than not checking at all. Because as I said it would
be possible to use mmap+mprotect to bypass IMA for shared libraries checking.

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

[Mimi Zohar]

On Tue, 2019-03-19 at 15:19 +0300, Igor Zhbanov wrote:
> On 19.03.2019 14:22, Mimi Zohar wrote:
> > On Tue, 2019-03-19 at 10:50 +0300, Igor Zhbanov wrote:
> >> Hi Mimi,
> >>
> >> I guess similar to SELinux function:
> > [snip]
> > 
> > Remember IMA relies on LSMs for mandatory access control(MAC).  IMA
> > measures, audits, and enforces file integrity.
> 
> Yes. But LSM will not check integrity of the file mmaped for read. Nor does
> IMA.
> 

Ok, so we can start there and modify the existing ima_file_mmap() to
verify file signatures that are being mmap'ed read.  The question will
then become what to do with mprotect write and execute.

> >> The structure vm_area_struct has a pointer vm_file pointing to mapped file
> >> so it could be used what file's xattrs to check.
> > 
> > That's fine for when there is a file descriptor, but the file
> > descriptor could have been closed.  (Refer to the mmap manpage.)
> 
> Can it be checked?
> 
> I think that checking the integrity at least in the case when the file is
> still open is better than not checking at all. Because as I said it would
> be possible to use mmap+mprotect to bypass IMA for shared libraries checking.

And what would you do with the mprotect without a file descriptor?

The mmap signature verification status is cached in the iint, based on
the inode.  I think whatever solution will need to be able to access
this cached information.

Mimi

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

[Matthew Garrett]

On Tue, Mar 19, 2019 at 5:19 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> I think that checking the integrity at least in the case when the file is
> still open is better than not checking at all. Because as I said it would
> be possible to use mmap+mprotect to bypass IMA for shared libraries checking.

Remember that an application can also open a file read-only and then
execute the code under an interpreter. If you have code that's
deliberately trying to undermine IMA then it can do so - the goal is
to use IMA to ensure that you have appropriate measurement or
appraisal in order to avoid that in the first place.

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

[Igor Zhbanov]

On 19.03.2019 20:05, Mimi Zohar wrote:
> Ok, so we can start there and modify the existing ima_file_mmap() to
> verify file signatures that are being mmap'ed read.  The question will
> then become what to do with mprotect write and execute.
> 
> And what would you do with the mprotect without a file descriptor?
> 
> The mmap signature verification status is cached in the iint, based on
> the inode.  I think whatever solution will need to be able to access
> this cached information.

Well, I think that IMA should check every executable page having a backing
storage, i.e. when a page is mmapped from a file. So it will not be possible
to store any new untrusted code on the disk.

(Except of reading it into read-only page, then creating anonymous executable
page and copying it there.)

As for creating anonymous executable pages, yes, there is nothing to check.
May be there should be some another LSM or prctl for that: whether some
process should have anonymous executable pages at all. I think that since
stack and data should be non-executable, normal apps should not have any
anonymous executable pages at all.

On 19.03.2019 20:07, Matthew Garrett wrote:
> Remember that an application can also open a file read-only and then
> execute the code under an interpreter. If you have code that's
> deliberately trying to undermine IMA then it can do so - the goal is
> to use IMA to ensure that you have appropriate measurement or
> appraisal in order to avoid that in the first place.

As for scripts interpreters like bash, yes, it will not protect against it.
But IMA can check e.g. all files read by root including non-executable ones.

My point was about better protecting of shared libraries making life harder
for exploits that are downloading extra code from external servers.

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

[Matthew Garrett]

On Wed, Mar 20, 2019 at 1:11 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:

> As for scripts interpreters like bash, yes, it will not protect against it.
> But IMA can check e.g. all files read by root including non-executable ones.

Non-JIT x86 emulators are basically just interpreters.

> My point was about better protecting of shared libraries making life harder
> for exploits that are downloading extra code from external servers.

Like you said, they can implement this by copying the code from
read-only pages to separate executable pages. It does make it harder,
but not to a huge degree - anything that's mprotect()ing file-backed
pages to PROT_EXEC later is presumably doing so to avoid IMA, and
making this change will just encourage them to add further
workarounds. Since this is a fight we literally can't win, what's the
benefit?

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

[Igor Zhbanov]

On 20.03.2019 20:23, Matthew Garrett wrote:
> On Wed, Mar 20, 2019 at 1:11 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> My point was about better protecting of shared libraries making life harder
>> for exploits that are downloading extra code from external servers.
> 
> Like you said, they can implement this by copying the code from
> read-only pages to separate executable pages. It does make it harder,
> but not to a huge degree - anything that's mprotect()ing file-backed
> pages to PROT_EXEC later is presumably doing so to avoid IMA, and
> making this change will just encourage them to add further
> workarounds. Since this is a fight we literally can't win, what's the
> benefit?

Well, may be it would be enough to:
1) Verify with IMA every file root processes read,
2) Use seccomp to forbid mprotect(..., PROT_EXEC) for 99% of processes,
    so they would have to use normal mmap(..., PROT_EXEC, ...) to load the
    code.

P.S. #2 should also protect against patching already mapped executable pages
because they are typically mapped read-only, so one would use
mprotect(..., PROT_READ | PROT_WRITE | PROT_EXEC) to enable write access
to it. So with #2 it wouldn't even be possible to reuse already mapped
pages nor to create new.

May be #2 could be implemented as a separate thing to avoid writing eBPF
seccomp filters to check mprotect() argument for rised PROT_EXEC flag.

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

[Mimi Zohar]

[Cc'ing Jann Horn, who brought this topic up last year.]

On Wed, 2019-03-20 at 10:23 -0700, Matthew Garrett wrote:
> On Wed, Mar 20, 2019 at 1:11 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:

<snip>

> > My point was about better protecting of shared libraries making life harder
> > for exploits that are downloading extra code from external servers.
> 
> Like you said, they can implement this by copying the code from
> read-only pages to separate executable pages. It does make it harder,
> but not to a huge degree - anything that's mprotect()ing file-backed
> pages to PROT_EXEC later is presumably doing so to avoid IMA, and
> making this change will just encourage them to add further
> workarounds. Since this is a fight we literally can't win, what's the
> benefit?

Really, Matthew?  Such gloomy thoughts coming from someone advocating
the "lockdown" patch set and extending IMA/EVM.  Part of our job
description as Linux kernel security/integrity developers is exactly
that - to make it more difficult for attackers, by hardening the
system and closing one measurement/appraisal gap at a time.

Igor, as for shared libraries:

1. Extend ima_file_mmap() to permit, based on policy, verifying file
signatures for files being mmap'ed read and preventing validly signed
files from being mmap'ed write.

2. Define an IMA mprotect hook that permits, based on policy,
preventing memory having validly signed backing storage from setting
the memory region to write, but allow execute.

(This will require access to the IMA mmap signature verification
status cached in the "iint".)

Mimi

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

[Igor Zhbanov]

On 21.03.2019 14:21, Mimi Zohar wrote:
> <snip>
> Igor, as for shared libraries:
> 
> 1. Extend ima_file_mmap() to permit, based on policy, verifying file
> signatures for files being mmap'ed read and preventing validly signed
> files from being mmap'ed write.
> 
> 2. Define an IMA mprotect hook that permits, based on policy,
> preventing memory having validly signed backing storage from setting
> the memory region to write, but allow execute.
> 
> (This will require access to the IMA mmap signature verification
> status cached in the "iint".)

Yes, it could work.

Pages mapped from the signed backing store rarely need to be altered
so preventing them from being changed will work.

Along with disabling creating anonymous executable pages at all since
is is hardly needed for the system services for normal work.

It could block polymorphic code so only ROP (return-oriented programming)
could survive after intercepting of execution flow without having an ability
to download any extra code from their servers.

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

[Matthew Garrett]

On Thu, Mar 21, 2019 at 4:48 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> Along with disabling creating anonymous executable pages at all since
> is is hardly needed for the system services for normal work.

Is this true? Do no JIT compilers behave this way?

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

[Matthew Garrett]

On Thu, Mar 21, 2019 at 4:22 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
>
> [Cc'ing Jann Horn, who brought this topic up last year.]
>
> On Wed, 2019-03-20 at 10:23 -0700, Matthew Garrett wrote:
> >
> > Like you said, they can implement this by copying the code from
> > read-only pages to separate executable pages. It does make it harder,
> > but not to a huge degree - anything that's mprotect()ing file-backed
> > pages to PROT_EXEC later is presumably doing so to avoid IMA, and
> > making this change will just encourage them to add further
> > workarounds. Since this is a fight we literally can't win, what's the
> > benefit?
>
> Really, Matthew?  Such gloomy thoughts coming from someone advocating
> the "lockdown" patch set and extending IMA/EVM.  Part of our job
> description as Linux kernel security/integrity developers is exactly
> that - to make it more difficult for attackers, by hardening the
> system and closing one measurement/appraisal gap at a time.

The question is whether it really makes it more difficult for
attackers :) If we block one avenue but leave another open, we haven't
won that much - we've added complexity to the kernel, but the
attackers are still able to inject code. Fundamentally, I can't see
any way we can prevent all avenues of code injection - instead I've
interpreted IMA appraisal as a statement that we believe the signed
binary won't deliberately attempt to circumvent our security model,
and then the problem goes away.

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

[Igor Zhbanov]

On 21.03.2019 21:04, Matthew Garrett wrote:
> On Thu, Mar 21, 2019 at 4:48 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
>> Along with disabling creating anonymous executable pages at all since
>> is is hardly needed for the system services for normal work.
> 
> Is this true? Do no JIT compilers behave this way?

Well, besides JIT I've scanned all /proc/PID/maps of my web-server and didn't
find any process with mapped anonymous executable pages.

As for JIT I suppose we could use prctl or something else to allow having
anonymous executable pages.

I'm pondering about some system-wide (or processes subtree-wide) default
setting controlling whether it is allowed to have anonymous pages by default,
and then some mechanism to turn it on/off on a per-process bases. Perhaps
with some locking preventing reenabling after it was dropped.

And what do you think about it?

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

[Mimi Zohar]

[Cc'ing Kees]

On Fri, 2019-03-22 at 10:59 +0300, Igor Zhbanov wrote:
> On 21.03.2019 21:04, Matthew Garrett wrote:
> > On Thu, Mar 21, 2019 at 4:48 AM Igor Zhbanov <i.zhbanov@omprussia.ru> wrote:
> >> Along with disabling creating anonymous executable pages at all since
> >> is is hardly needed for the system services for normal work.
> > 
> > Is this true? Do no JIT compilers behave this way?
> 
> Well, besides JIT I've scanned all /proc/PID/maps of my web-server and didn't
> find any process with mapped anonymous executable pages.
> 
> As for JIT I suppose we could use prctl or something else to allow having
> anonymous executable pages.
> 
> I'm pondering about some system-wide (or prosses subtree-wide) default
> setting controlling whether it is allowed to have anonymous pages by default,
> and then some mechanism to turn it on/off on a per-process bases. Perhaps
> with some locking preventing reenabling after it was dropped.
> 
> And what do you think about it?

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?

Mimi

[1]https://pax.grsecurity.net/docs/mprotect.txt 

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

[Igor Zhbanov]

Hi Mimi,

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.

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

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?

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

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

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

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

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.