* LSM that blocks execution of the code from the anonymous pages @ 2020-09-03 16:20 Igor Zhbanov 2020-09-17 18:11 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Igor Zhbanov @ 2020-09-03 16:20 UTC (permalink / raw) To: linux-integrity 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LSM that blocks execution of the code from the anonymous pages 2020-09-03 16:20 LSM that blocks execution of the code from the anonymous pages Igor Zhbanov @ 2020-09-17 18:11 ` Mimi Zohar 2020-09-17 20:39 ` Igor Zhbanov 0 siblings, 1 reply; 4+ messages in thread From: Mimi Zohar @ 2020-09-17 18:11 UTC (permalink / raw) To: Igor Zhbanov, linux-integrity 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LSM that blocks execution of the code from the anonymous pages 2020-09-17 18:11 ` Mimi Zohar @ 2020-09-17 20:39 ` Igor Zhbanov 2020-09-17 20:53 ` Mimi Zohar 0 siblings, 1 reply; 4+ messages in thread From: Igor Zhbanov @ 2020-09-17 20:39 UTC (permalink / raw) To: Mimi Zohar, linux-integrity 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: LSM that blocks execution of the code from the anonymous pages 2020-09-17 20:39 ` Igor Zhbanov @ 2020-09-17 20:53 ` Mimi Zohar 0 siblings, 0 replies; 4+ messages in thread From: Mimi Zohar @ 2020-09-17 20:53 UTC (permalink / raw) To: Igor Zhbanov, linux-integrity; +Cc: linux-security-module 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-17 21:22 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-03 16:20 LSM that blocks execution of the code from the anonymous pages Igor Zhbanov 2020-09-17 18:11 ` Mimi Zohar 2020-09-17 20:39 ` Igor Zhbanov 2020-09-17 20:53 ` Mimi Zohar
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.