* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? [not found] ` <92718382-8669-748f-10d8-02fa21225210@omprussia.ru> @ 2019-03-29 10:59 ` Mimi Zohar 2019-03-29 11:51 ` Jordan Glover 2019-03-29 12:28 ` Stephen Smalley 0 siblings, 2 replies; 19+ messages in thread From: Mimi Zohar @ 2019-03-29 10:59 UTC (permalink / raw) To: Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Stephen Smalley, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module [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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-03-29 10:59 ` Should mprotect(..., PROT_EXEC) be checked by IMA? Mimi Zohar @ 2019-03-29 11:51 ` Jordan Glover 2019-03-29 12:28 ` Stephen Smalley 1 sibling, 0 replies; 19+ messages in thread From: Jordan Glover @ 2019-03-29 11:51 UTC (permalink / raw) To: Mimi Zohar Cc: Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Stephen Smalley, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-03-29 10:59 ` Should mprotect(..., PROT_EXEC) be checked by IMA? Mimi Zohar 2019-03-29 11:51 ` Jordan Glover @ 2019-03-29 12:28 ` Stephen Smalley 2019-03-29 12:50 ` Igor Zhbanov 1 sibling, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2019-03-29 12:28 UTC (permalink / raw) To: Mimi Zohar, Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-03-29 12:28 ` Stephen Smalley @ 2019-03-29 12:50 ` Igor Zhbanov 2019-04-02 22:31 ` Matthew Garrett 2019-04-03 11:57 ` Mimi Zohar 0 siblings, 2 replies; 19+ messages in thread From: Igor Zhbanov @ 2019-03-29 12:50 UTC (permalink / raw) To: Stephen Smalley, Mimi Zohar, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-03-29 12:50 ` Igor Zhbanov @ 2019-04-02 22:31 ` Matthew Garrett 2019-04-03 9:59 ` Igor Zhbanov 2019-04-03 12:11 ` Mimi Zohar 2019-04-03 11:57 ` Mimi Zohar 1 sibling, 2 replies; 19+ messages in thread From: Matthew Garrett @ 2019-04-02 22:31 UTC (permalink / raw) To: Igor Zhbanov Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-02 22:31 ` Matthew Garrett @ 2019-04-03 9:59 ` Igor Zhbanov 2019-04-03 16:58 ` Matthew Garrett 2019-04-03 12:11 ` Mimi Zohar 1 sibling, 1 reply; 19+ messages in thread From: Igor Zhbanov @ 2019-04-03 9:59 UTC (permalink / raw) To: Matthew Garrett Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 9:59 ` Igor Zhbanov @ 2019-04-03 16:58 ` Matthew Garrett 2019-04-03 17:31 ` Igor Zhbanov 0 siblings, 1 reply; 19+ messages in thread From: Matthew Garrett @ 2019-04-03 16:58 UTC (permalink / raw) To: Igor Zhbanov Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 16:58 ` Matthew Garrett @ 2019-04-03 17:31 ` Igor Zhbanov 2019-04-03 18:19 ` Matthew Garrett 0 siblings, 1 reply; 19+ messages in thread From: Igor Zhbanov @ 2019-04-03 17:31 UTC (permalink / raw) To: Matthew Garrett Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 17:31 ` Igor Zhbanov @ 2019-04-03 18:19 ` Matthew Garrett 2019-04-03 18:47 ` Igor Zhbanov 0 siblings, 1 reply; 19+ messages in thread From: Matthew Garrett @ 2019-04-03 18:19 UTC (permalink / raw) To: Igor Zhbanov Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 18:19 ` Matthew Garrett @ 2019-04-03 18:47 ` Igor Zhbanov 2019-04-03 19:25 ` Matthew Garrett 0 siblings, 1 reply; 19+ messages in thread From: Igor Zhbanov @ 2019-04-03 18:47 UTC (permalink / raw) To: Matthew Garrett Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 18:47 ` Igor Zhbanov @ 2019-04-03 19:25 ` Matthew Garrett 2019-04-04 11:44 ` Igor Zhbanov 0 siblings, 1 reply; 19+ messages in thread From: Matthew Garrett @ 2019-04-03 19:25 UTC (permalink / raw) To: Igor Zhbanov Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 19:25 ` Matthew Garrett @ 2019-04-04 11:44 ` Igor Zhbanov 0 siblings, 0 replies; 19+ messages in thread From: Igor Zhbanov @ 2019-04-04 11:44 UTC (permalink / raw) To: Matthew Garrett Cc: Stephen Smalley, Mimi Zohar, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-02 22:31 ` Matthew Garrett 2019-04-03 9:59 ` Igor Zhbanov @ 2019-04-03 12:11 ` Mimi Zohar 2019-04-03 13:18 ` Perez Yves-Alexis 1 sibling, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2019-04-03 12:11 UTC (permalink / raw) To: Matthew Garrett, Igor Zhbanov Cc: Stephen Smalley, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 12:11 ` Mimi Zohar @ 2019-04-03 13:18 ` Perez Yves-Alexis 0 siblings, 0 replies; 19+ messages in thread From: Perez Yves-Alexis @ 2019-04-03 13:18 UTC (permalink / raw) To: Mimi Zohar, Matthew Garrett, Igor Zhbanov Cc: Stephen Smalley, Kees Cook, Casey Schaufler, Paul Moore, John Johansen, linux-integrity, Jann Horn, linux-security-module, Mickaël Salaün, Yves-Alexis Perez, Mickaël Salaün 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-03-29 12:50 ` Igor Zhbanov 2019-04-02 22:31 ` Matthew Garrett @ 2019-04-03 11:57 ` Mimi Zohar 2019-04-03 13:10 ` Stephen Smalley 1 sibling, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2019-04-03 11:57 UTC (permalink / raw) To: Igor Zhbanov, Stephen Smalley, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 11:57 ` Mimi Zohar @ 2019-04-03 13:10 ` Stephen Smalley 2019-04-03 14:33 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2019-04-03 13:10 UTC (permalink / raw) To: Mimi Zohar, Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 13:10 ` Stephen Smalley @ 2019-04-03 14:33 ` Mimi Zohar 2019-04-03 14:33 ` Stephen Smalley 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2019-04-03 14:33 UTC (permalink / raw) To: Stephen Smalley, Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 14:33 ` Mimi Zohar @ 2019-04-03 14:33 ` Stephen Smalley 2019-04-03 16:21 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Stephen Smalley @ 2019-04-03 14:33 UTC (permalink / raw) To: Mimi Zohar, Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA? 2019-04-03 14:33 ` Stephen Smalley @ 2019-04-03 16:21 ` Mimi Zohar 0 siblings, 0 replies; 19+ messages in thread From: Mimi Zohar @ 2019-04-03 16:21 UTC (permalink / raw) To: Stephen Smalley, Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler, Paul Moore, John Johansen Cc: linux-integrity, Jann Horn, linux-security-module 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2019-04-04 11:44 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <cce2c4c7-5333-41c3-aeef-34d43e63acb0@omprussia.ru>
[not found] ` <1552945715.8658.299.camel@linux.ibm.com>
[not found] ` <452752df-98f9-c361-878a-5df84ab36847@omprussia.ru>
[not found] ` <1552994559.4899.26.camel@linux.ibm.com>
[not found] ` <84145490-6f70-214f-8241-42d556590240@omprussia.ru>
[not found] ` <1553015134.4899.82.camel@linux.ibm.com>
[not found] ` <a9830bde-8157-6078-b544-fcffb20d2501@omprussia.ru>
[not found] ` <CACdnJut6YfLnq-nCC1hHTrKYXabHoSEXN1wMuCyVybU+o_iwCg@mail.gmail.com>
[not found] ` <1553167318.4899.382.camel@linux.ibm.com>
[not found] ` <dab923ca-ef53-4af2-034a-bea4151a4e25@omprussia.ru>
[not found] ` <CACdnJuvVqibDdd+MLKOHqEfdngTk=GSkfybj1jS3MpmC7rjyHg@mail.gmail.com>
[not found] ` <07347317-ee71-83c1-384a-0c3439980af7@omprussia.ru>
[not found] ` <1553793463.8711.26.camel@linux.ibm.com>
[not found] ` <92718382-8669-748f-10d8-02fa21225210@omprussia.ru>
2019-03-29 10:59 ` Should mprotect(..., PROT_EXEC) be checked by IMA? Mimi Zohar
2019-03-29 11:51 ` Jordan Glover
2019-03-29 12:28 ` Stephen Smalley
2019-03-29 12:50 ` Igor Zhbanov
2019-04-02 22:31 ` Matthew Garrett
2019-04-03 9:59 ` Igor Zhbanov
2019-04-03 16:58 ` Matthew Garrett
2019-04-03 17:31 ` Igor Zhbanov
2019-04-03 18:19 ` Matthew Garrett
2019-04-03 18:47 ` Igor Zhbanov
2019-04-03 19:25 ` Matthew Garrett
2019-04-04 11:44 ` Igor Zhbanov
2019-04-03 12:11 ` Mimi Zohar
2019-04-03 13:18 ` Perez Yves-Alexis
2019-04-03 11:57 ` Mimi Zohar
2019-04-03 13:10 ` Stephen Smalley
2019-04-03 14:33 ` Mimi Zohar
2019-04-03 14:33 ` Stephen Smalley
2019-04-03 16:21 ` Mimi Zohar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).