LSM that blocks execution of the code from the anonymous pages

LSM that blocks execution of the code from the anonymous pages

[Igor Zhbanov]

Hello!

Earlier in the therad "Should mprotect(..., PROT_EXEC) be checked by IMA?"
we've discussed whether IMA should intercept making executable of anonymous
pages.

I've implemented simple LSM that blocks execution of the code from anonymous
pages, like: mmap(RW) + read_unsigned_code_from_file() + mprotect(RX).

Currently it uses hooks similar to selinux_mmap_file() and
selinux_file_mprotect() to restrict any privileged processes (any uid is 0,
or any gid is 0 or any capability is set) from executing of anonymous unsigned
code.

The IMA module is specializing in file-backed (non-anonymous) code integrity
measurement while allowing execution of arbitrary anonymous code. In
conjunction with my LSM it would be possible to be sure that any code that is
executed on a device is trusted.

This would prevent malware payloads from being downloaded and executed in
both file-backed and anonymous memory. For example, there is even a framework
for making of filless malware:
https://www.prodefence.org/fireelf-fileless-linux-malware-framework/
Also there is an article about execution of ELFs from memory:
https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html
https://blog.fbkcs.ru/elf-in-memory-execution/

So it could be an independent LSM or extension of the LSM IMA functionality.

Also I'm thinking about extending working modes to:
1) no anonomous code for privileged processes (as currently),
2) no anonomous code for all processes,
3) no anonomous code for all processes with xattr-based exceptions (may be
    with xattr value signing)

I've found that some applications like browsers are using anonymous code
pages for JavaScript JIT code. Also some processes are using libffi that also
modifies to code. But it looks like it's possible to rebuild libffi with
trampoline support (PaX compatibility mode) to avoid altering the code pages.
Also QML-based application also use JS JIT. (And may be python scripts too.)

So for some (mostly unprivileged processes) we would need to make the
exceptions. But for most of the privileged system services (that is a good
target for attack because of their ptivileges) there is no need in code pages
modification, so the proposed functionality could be used to protect them,
as well as in embedded world where could be no user processes with JIT at all.

So IMA with this LSM would ensure that all the code that is executes is
trusted, signed and verified.

What do you think?

Thank you.

Re: LSM that blocks execution of the code from the anonymous pages

[Mimi Zohar]

Hi Igor,

Sorry for the delay in responding.

On Thu, 2020-09-03 at 19:20 +0300, Igor Zhbanov wrote:
> Hello!
> 
> Earlier in the therad "Should mprotect(..., PROT_EXEC) be checked by IMA?"
> we've discussed whether IMA should intercept making executable of anonymous
> pages.
> 
> I've implemented simple LSM that blocks execution of the code from anonymous
> pages, like: mmap(RW) + read_unsigned_code_from_file() + mprotect(RX).
> 
> Currently it uses hooks similar to selinux_mmap_file() and
> selinux_file_mprotect() to restrict any privileged processes (any uid is 0,
> or any gid is 0 or any capability is set) from executing of anonymous unsigned
> code.
> 
> The IMA module is specializing in file-backed (non-anonymous) code integrity
> measurement while allowing execution of arbitrary anonymous code. In
> conjunction with my LSM it would be possible to be sure that any code that is
> executed on a device is trusted.
> 
> This would prevent malware payloads from being downloaded and executed in
> both file-backed and anonymous memory. For example, there is even a framework
> for making of filless malware:
> https://www.prodefence.org/fireelf-fileless-linux-malware-framework/
> Also there is an article about execution of ELFs from memory:
> https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html
> https://blog.fbkcs.ru/elf-in-memory-execution/
> 
> So it could be an independent LSM or extension of the LSM IMA functionality.
> 
> Also I'm thinking about extending working modes to:
> 1) no anonomous code for privileged processes (as currently),
> 2) no anonomous code for all processes,
> 3) no anonomous code for all processes with xattr-based exceptions (may be
>     with xattr value signing)
> 
> I've found that some applications like browsers are using anonymous code
> pages for JavaScript JIT code. Also some processes are using libffi that also
> modifies to code. But it looks like it's possible to rebuild libffi with
> trampoline support (PaX compatibility mode) to avoid altering the code pages.
> Also QML-based application also use JS JIT. (And may be python scripts too.)
> 
> So for some (mostly unprivileged processes) we would need to make the
> exceptions. But for most of the privileged system services (that is a good
> target for attack because of their ptivileges) there is no need in code pages
> modification, so the proposed functionality could be used to protect them,
> as well as in embedded world where could be no user processes with JIT at all.
> 
> So IMA with this LSM would ensure that all the code that is executes is
> trusted, signed and verified.
> 
> What do you think?

Preventing malware payloads from being downloaded and executed as
either file-backed or from anonymous memory is really important.  As
long as IMA has the ability to define a system wide integrity policy,
it doesn't make a difference whether blocking anonymous pages is part
of IMA or as a separate LSM.

If it's a separate LSM, then IMA would delegate responsibility for
enforcing the IMA policy to the LSM.

thanks,

Mimi

Re: LSM that blocks execution of the code from the anonymous pages

[Igor Zhbanov]

Hi Mimi,

My question is more about whether this functionality fits into IMA's
responsibility. I.e. I can propose the changes as the extension of IMA's
functionality (which I think it would be better), or I could create a separate
LSM if this functionality doesn't align with IMA's purpose for some reason.
This is the first question.

And the second question, what kind of operation modes do you think would
be useful?

1) no anonymous code for privileged processes (as currently),
2) no anonymous code for all processes,
3) no anonymous code for all processes with xattr-based exceptions (may be
      with xattr value signing)

For #3 I definitely would prefer to implement the code as a part of IMA
because of sharing of xattrs cache, etc. to avoid reinventing the wheel.

Thank you.

On 17.09.2020 21:11, Mimi Zohar wrote:
> Hi Igor,
> 
> Sorry for the delay in responding.
> 
> On Thu, 2020-09-03 at 19:20 +0300, Igor Zhbanov wrote:
>> Hello!
>>
>> Earlier in the therad "Should mprotect(..., PROT_EXEC) be checked by IMA?"
>> we've discussed whether IMA should intercept making executable of anonymous
>> pages.
>>
>> I've implemented simple LSM that blocks execution of the code from anonymous
>> pages, like: mmap(RW) + read_unsigned_code_from_file() + mprotect(RX).
>>
>> Currently it uses hooks similar to selinux_mmap_file() and
>> selinux_file_mprotect() to restrict any privileged processes (any uid is 0,
>> or any gid is 0 or any capability is set) from executing of anonymous unsigned
>> code.
>>
>> The IMA module is specializing in file-backed (non-anonymous) code integrity
>> measurement while allowing execution of arbitrary anonymous code. In
>> conjunction with my LSM it would be possible to be sure that any code that is
>> executed on a device is trusted.
>>
>> This would prevent malware payloads from being downloaded and executed in
>> both file-backed and anonymous memory. For example, there is even a framework
>> for making of filless malware:
>> https://www.prodefence.org/fireelf-fileless-linux-malware-framework/
>> Also there is an article about execution of ELFs from memory:
>> https://magisterquis.github.io/2018/03/31/in-memory-only-elf-execution.html
>> https://blog.fbkcs.ru/elf-in-memory-execution/
>>
>> So it could be an independent LSM or extension of the LSM IMA functionality.
>>
>> Also I'm thinking about extending working modes to:
>> 1) no anonomous code for privileged processes (as currently),
>> 2) no anonomous code for all processes,
>> 3) no anonomous code for all processes with xattr-based exceptions (may be
>>      with xattr value signing)
>>
>> I've found that some applications like browsers are using anonymous code
>> pages for JavaScript JIT code. Also some processes are using libffi that also
>> modifies to code. But it looks like it's possible to rebuild libffi with
>> trampoline support (PaX compatibility mode) to avoid altering the code pages.
>> Also QML-based application also use JS JIT. (And may be python scripts too.)
>>
>> So for some (mostly unprivileged processes) we would need to make the
>> exceptions. But for most of the privileged system services (that is a good
>> target for attack because of their ptivileges) there is no need in code pages
>> modification, so the proposed functionality could be used to protect them,
>> as well as in embedded world where could be no user processes with JIT at all.
>>
>> So IMA with this LSM would ensure that all the code that is executes is
>> trusted, signed and verified.
>>
>> What do you think?
> 
> Preventing malware payloads from being downloaded and executed as
> either file-backed or from anonymous memory is really important.  As
> long as IMA has the ability to define a system wide integrity policy,
> it doesn't make a difference whether blocking anonymous pages is part
> of IMA or as a separate LSM.
> 
> If it's a separate LSM, then IMA would delegate responsibility for
> enforcing the IMA policy to the LSM.


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

Re: LSM that blocks execution of the code from the anonymous pages

[Mimi Zohar]

Hi Igor,

(Reminder the Linux kernel mailing lists convention is to inline/bottom
post.)

On Thu, 2020-09-17 at 23:39 +0300, Igor Zhbanov wrote:
> My question is more about whether this functionality fits into IMA's
> responsibility. I.e. I can propose the changes as the extension of IMA's
> functionality (which I think it would be better), or I could create a separate
> LSM if this functionality doesn't align with IMA's purpose for some reason.
> This is the first question.
> 
> And the second question, what kind of operation modes do you think would
> be useful?
> 
> 1) no anonymous code for privileged processes (as currently),
> 2) no anonymous code for all processes,
> 3) no anonymous code for all processes with xattr-based exceptions (may be
>       with xattr value signing)

These are generic questions not dependent on whether this would be
upstreamed as an independent LSM or as part of IMA.  For this reason,
I've Cc'ed the LSM mailing list.

Mimi

> 
> For #3 I definitely would prefer to implement the code as a part of IMA
> because of sharing of xattrs cache, etc. to avoid reinventing the wheel.