| Message ID | 20200505153156.925111-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add support for O_MAYEXEC | expand |
On 05/05/2020 17:31, Mickaël Salaün wrote: > Hi, > > This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, > OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to > configure the security policy at kernel build time. As requested by > Mimi Zohar, I completed the series with one of her patches for IMA. > > The goal of this patch series is to enable to control script execution > with interpreters help. A new O_MAYEXEC flag, usable through > openat2(2), is added to enable userspace script interpreter to delegate > to the kernel (and thus the system security policy) the permission to > interpret/execute scripts or other files containing what can be seen as > commands. > > A simple system-wide security policy can be enforced by the system > administrator through a sysctl configuration consistent with the mount > points or the file access rights. The documentation patch explains the > prerequisites. > > Furthermore, the security policy can also be delegated to an LSM, either > a MAC system or an integrity system. For instance, the new kernel > MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter > integrity gap by bringing the ability to check the use of scripts [1]. > Other uses are expected, such as for openat2(2) [2], SGX integration > [3], bpffs [4] or IPE [5]. > > Userspace needs to adapt to take advantage of this new feature. For > example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be > extended with policy enforcement points related to code interpretation, > which can be used to align with the PowerShell audit features. > Additional Python security improvements (e.g. a limited interpreter > withou -c, stdin piping of code) are on their way. > > The initial idea come from CLIP OS 4 and the original implementation has > been used for more than 12 years: > https://github.com/clipos-archive/clipos4_doc > > An introduction to O_MAYEXEC was given at the Linux Security Summit > Europe 2018 - Linux Kernel Security Contributions by ANSSI: > https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s > The "write xor execute" principle was explained at Kernel Recipes 2018 - > CLIP OS: a defense-in-depth OS: > https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s > > This patch series can be applied on top of v5.7-rc4. This can be tested > with CONFIG_SYSCTL. I would really appreciate constructive comments on > this patch series. > > Previous version: > https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/ The previous version (v4) is https://lore.kernel.org/lkml/20200430132320.699508-1-mic@digikod.net/
On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün <mic@digikod.net> wrote: > > > On 05/05/2020 17:31, Mickaël Salaün wrote: > > Hi, > > > > This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, > > OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to > > configure the security policy at kernel build time. As requested by > > Mimi Zohar, I completed the series with one of her patches for IMA. > > > > The goal of this patch series is to enable to control script execution > > with interpreters help. A new O_MAYEXEC flag, usable through > > openat2(2), is added to enable userspace script interpreter to delegate > > to the kernel (and thus the system security policy) the permission to > > interpret/execute scripts or other files containing what can be seen as > > commands. > > > > A simple system-wide security policy can be enforced by the system > > administrator through a sysctl configuration consistent with the mount > > points or the file access rights. The documentation patch explains the > > prerequisites. > > > > Furthermore, the security policy can also be delegated to an LSM, either > > a MAC system or an integrity system. For instance, the new kernel > > MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter > > integrity gap by bringing the ability to check the use of scripts [1]. > > Other uses are expected, such as for openat2(2) [2], SGX integration > > [3], bpffs [4] or IPE [5]. > > > > Userspace needs to adapt to take advantage of this new feature. For > > example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be > > extended with policy enforcement points related to code interpretation, > > which can be used to align with the PowerShell audit features. > > Additional Python security improvements (e.g. a limited interpreter > > withou -c, stdin piping of code) are on their way. > > > > The initial idea come from CLIP OS 4 and the original implementation has > > been used for more than 12 years: > > https://github.com/clipos-archive/clipos4_doc > > > > An introduction to O_MAYEXEC was given at the Linux Security Summit > > Europe 2018 - Linux Kernel Security Contributions by ANSSI: > > https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s > > The "write xor execute" principle was explained at Kernel Recipes 2018 - > > CLIP OS: a defense-in-depth OS: > > https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s > > > > This patch series can be applied on top of v5.7-rc4. This can be tested > > with CONFIG_SYSCTL. I would really appreciate constructive comments on > > this patch series. > > > > Previous version: > > https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/ > > The previous version (v4) is > https://lore.kernel.org/lkml/20200430132320.699508-1-mic@digikod.net/ Hi Michael I have couple of question 1. Why you did not add O_MAYEXEC to open()? Some time ago (around v4.14) open() did not return EINVAL when VALID_OPEN_FLAGS check failed. Now it does, so I do not see a problem that interpreter will use simple open(), ( Although that path might be manipulated, but file contents will be verified by IMA) 2. When you apply a new flag to mount, it means that IMA will check all files under this mount and it does not matter whether the file in question is a script or not. IMHO it is too hard overhead for performance reasons. Regards, LEv
On 2020-05-06, Lev R. Oshvang . <levonshe@gmail.com> wrote: > On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün <mic@digikod.net> wrote: > > > > > > On 05/05/2020 17:31, Mickaël Salaün wrote: > > > Hi, > > > > > > This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, > > > OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to > > > configure the security policy at kernel build time. As requested by > > > Mimi Zohar, I completed the series with one of her patches for IMA. > > > > > > The goal of this patch series is to enable to control script execution > > > with interpreters help. A new O_MAYEXEC flag, usable through > > > openat2(2), is added to enable userspace script interpreter to delegate > > > to the kernel (and thus the system security policy) the permission to > > > interpret/execute scripts or other files containing what can be seen as > > > commands. > > > > > > A simple system-wide security policy can be enforced by the system > > > administrator through a sysctl configuration consistent with the mount > > > points or the file access rights. The documentation patch explains the > > > prerequisites. > > > > > > Furthermore, the security policy can also be delegated to an LSM, either > > > a MAC system or an integrity system. For instance, the new kernel > > > MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter > > > integrity gap by bringing the ability to check the use of scripts [1]. > > > Other uses are expected, such as for openat2(2) [2], SGX integration > > > [3], bpffs [4] or IPE [5]. > > > > > > Userspace needs to adapt to take advantage of this new feature. For > > > example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be > > > extended with policy enforcement points related to code interpretation, > > > which can be used to align with the PowerShell audit features. > > > Additional Python security improvements (e.g. a limited interpreter > > > withou -c, stdin piping of code) are on their way. > > > > > > The initial idea come from CLIP OS 4 and the original implementation has > > > been used for more than 12 years: > > > https://github.com/clipos-archive/clipos4_doc > > > > > > An introduction to O_MAYEXEC was given at the Linux Security Summit > > > Europe 2018 - Linux Kernel Security Contributions by ANSSI: > > > https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s > > > The "write xor execute" principle was explained at Kernel Recipes 2018 - > > > CLIP OS: a defense-in-depth OS: > > > https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s > > > > > > This patch series can be applied on top of v5.7-rc4. This can be tested > > > with CONFIG_SYSCTL. I would really appreciate constructive comments on > > > this patch series. > > > > > > Previous version: > > > https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/ > > > > The previous version (v4) is > > https://lore.kernel.org/lkml/20200430132320.699508-1-mic@digikod.net/ > > > Hi Michael > > I have couple of question > 1. Why you did not add O_MAYEXEC to open()? > Some time ago (around v4.14) open() did not return EINVAL when > VALID_OPEN_FLAGS check failed. > Now it does, so I do not see a problem that interpreter will use > simple open(), ( Although that path might be manipulated, but file > contents will be verified by IMA) You don't get -EINVAL from open() in the case of unknown flags, that's something only openat2() does in the open*() family. Hence why it's only introduced for openat2(). > 2. When you apply a new flag to mount, it means that IMA will check > all files under this mount and it does not matter whether the file in > question is a script or not. > IMHO it is too hard overhead for performance reasons. > > Regards, > LEv
From: Mickaël Salaün > Sent: 05 May 2020 16:32 > > This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, > OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to > configure the security policy at kernel build time. As requested by > Mimi Zohar, I completed the series with one of her patches for IMA. > > The goal of this patch series is to enable to control script execution > with interpreters help. A new O_MAYEXEC flag, usable through > openat2(2), is added to enable userspace script interpreter to delegate > to the kernel (and thus the system security policy) the permission to > interpret/execute scripts or other files containing what can be seen as > commands. > > A simple system-wide security policy can be enforced by the system > administrator through a sysctl configuration consistent with the mount > points or the file access rights. The documentation patch explains the > prerequisites. > > Furthermore, the security policy can also be delegated to an LSM, either > a MAC system or an integrity system. For instance, the new kernel > MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter > integrity gap by bringing the ability to check the use of scripts [1]. > Other uses are expected, such as for openat2(2) [2], SGX integration > [3], bpffs [4] or IPE [5]. > > Userspace needs to adapt to take advantage of this new feature. For > example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be > extended with policy enforcement points related to code interpretation, > which can be used to align with the PowerShell audit features. > Additional Python security improvements (e.g. a limited interpreter > withou -c, stdin piping of code) are on their way. > > The initial idea come from CLIP OS 4 and the original implementation has > been used for more than 12 years: > https://github.com/clipos-archive/clipos4_doc > > An introduction to O_MAYEXEC was given at the Linux Security Summit > Europe 2018 - Linux Kernel Security Contributions by ANSSI: > https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s > The "write xor execute" principle was explained at Kernel Recipes 2018 - > CLIP OS: a defense-in-depth OS: > https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s > > This patch series can be applied on top of v5.7-rc4. This can be tested > with CONFIG_SYSCTL. I would really appreciate constructive comments on > this patch series. None of that description actually says what the patch actually does. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 06/05/2020 15:58, Lev R. Oshvang . wrote: > On Tue, May 5, 2020 at 6:36 PM Mickaël Salaün <mic@digikod.net> wrote: >> >> >> On 05/05/2020 17:31, Mickaël Salaün wrote: >>> Hi, >>> >>> This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, >>> OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to >>> configure the security policy at kernel build time. As requested by >>> Mimi Zohar, I completed the series with one of her patches for IMA. >>> >>> The goal of this patch series is to enable to control script execution >>> with interpreters help. A new O_MAYEXEC flag, usable through >>> openat2(2), is added to enable userspace script interpreter to delegate >>> to the kernel (and thus the system security policy) the permission to >>> interpret/execute scripts or other files containing what can be seen as >>> commands. >>> >>> A simple system-wide security policy can be enforced by the system >>> administrator through a sysctl configuration consistent with the mount >>> points or the file access rights. The documentation patch explains the >>> prerequisites. >>> >>> Furthermore, the security policy can also be delegated to an LSM, either >>> a MAC system or an integrity system. For instance, the new kernel >>> MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter >>> integrity gap by bringing the ability to check the use of scripts [1]. >>> Other uses are expected, such as for openat2(2) [2], SGX integration >>> [3], bpffs [4] or IPE [5]. >>> >>> Userspace needs to adapt to take advantage of this new feature. For >>> example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be >>> extended with policy enforcement points related to code interpretation, >>> which can be used to align with the PowerShell audit features. >>> Additional Python security improvements (e.g. a limited interpreter >>> withou -c, stdin piping of code) are on their way. >>> >>> The initial idea come from CLIP OS 4 and the original implementation has >>> been used for more than 12 years: >>> https://github.com/clipos-archive/clipos4_doc >>> >>> An introduction to O_MAYEXEC was given at the Linux Security Summit >>> Europe 2018 - Linux Kernel Security Contributions by ANSSI: >>> https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s >>> The "write xor execute" principle was explained at Kernel Recipes 2018 - >>> CLIP OS: a defense-in-depth OS: >>> https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s >>> >>> This patch series can be applied on top of v5.7-rc4. This can be tested >>> with CONFIG_SYSCTL. I would really appreciate constructive comments on >>> this patch series. >>> >>> Previous version: >>> https://lore.kernel.org/lkml/20200428175129.634352-1-mic@digikod.net/ >> >> The previous version (v4) is >> https://lore.kernel.org/lkml/20200430132320.699508-1-mic@digikod.net/ > > > Hi Michael > > I have couple of question > 1. Why you did not add O_MAYEXEC to open()? > Some time ago (around v4.14) open() did not return EINVAL when > VALID_OPEN_FLAGS check failed. > Now it does, so I do not see a problem that interpreter will use > simple open(), ( Although that path might be manipulated, but file > contents will be verified by IMA) Aleksa replied to this. > 2. When you apply a new flag to mount, it means that IMA will check > all files under this mount and it does not matter whether the file in > question is a script or not. > IMHO it is too hard overhead for performance reasons. This patch series doesn't change the way IMA handles mount points. > > Regards, > LEv >
On 07/05/2020 10:05, David Laight wrote: > From: Mickaël Salaün >> Sent: 05 May 2020 16:32 >> >> This fifth patch series add new kernel configurations (OMAYEXEC_STATIC, >> OMAYEXEC_ENFORCE_MOUNT, and OMAYEXEC_ENFORCE_FILE) to enable to >> configure the security policy at kernel build time. As requested by >> Mimi Zohar, I completed the series with one of her patches for IMA. >> >> The goal of this patch series is to enable to control script execution >> with interpreters help. A new O_MAYEXEC flag, usable through >> openat2(2), is added to enable userspace script interpreter to delegate >> to the kernel (and thus the system security policy) the permission to >> interpret/execute scripts or other files containing what can be seen as >> commands. >> >> A simple system-wide security policy can be enforced by the system >> administrator through a sysctl configuration consistent with the mount >> points or the file access rights. The documentation patch explains the >> prerequisites. >> >> Furthermore, the security policy can also be delegated to an LSM, either >> a MAC system or an integrity system. For instance, the new kernel >> MAY_OPENEXEC flag closes a major IMA measurement/appraisal interpreter >> integrity gap by bringing the ability to check the use of scripts [1]. >> Other uses are expected, such as for openat2(2) [2], SGX integration >> [3], bpffs [4] or IPE [5]. >> >> Userspace needs to adapt to take advantage of this new feature. For >> example, the PEP 578 [6] (Runtime Audit Hooks) enables Python 3.8 to be >> extended with policy enforcement points related to code interpretation, >> which can be used to align with the PowerShell audit features. >> Additional Python security improvements (e.g. a limited interpreter >> withou -c, stdin piping of code) are on their way. >> >> The initial idea come from CLIP OS 4 and the original implementation has >> been used for more than 12 years: >> https://github.com/clipos-archive/clipos4_doc >> >> An introduction to O_MAYEXEC was given at the Linux Security Summit >> Europe 2018 - Linux Kernel Security Contributions by ANSSI: >> https://www.youtube.com/watch?v=chNjCRtPKQY&t=17m15s >> The "write xor execute" principle was explained at Kernel Recipes 2018 - >> CLIP OS: a defense-in-depth OS: >> https://www.youtube.com/watch?v=PjRE0uBtkHU&t=11m14s >> >> This patch series can be applied on top of v5.7-rc4. This can be tested >> with CONFIG_SYSCTL. I would really appreciate constructive comments on >> this patch series. > > None of that description actually says what the patch actually does. "Add support for O_MAYEXEC" "to enable to control script execution". What is not clear here? This seems well understood by other commenters. The documentation patch and the talks can also help.
From: Mickaël Salaün > Sent: 07 May 2020 09:37 ... > > None of that description actually says what the patch actually does. > > "Add support for O_MAYEXEC" "to enable to control script execution". > What is not clear here? This seems well understood by other commenters. > The documentation patch and the talks can also help. I'm guessing that passing O_MAYEXEC to open() requests the kernel check for execute 'x' permissions (as well as read). Then kernel policy determines whether 'read' access is actually enough, or whether 'x' access (possibly masked by mount permissions) is needed. If that is true, two lines say what is does. Have you ever set a shell script permissions to --x--s--x ? Ends up being executable by everyone except the owner! Having the kernel pass all '#!' files to their interpreters through an open fd might help security. In that case the user doesn't need read access to the file in order to get an interpreter to process it. (You'd need to stop strace showing the contents to actually hide them.) David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 07/05/2020 11:00, David Laight wrote: > From: Mickaël Salaün >> Sent: 07 May 2020 09:37 > ... >>> None of that description actually says what the patch actually does. >> >> "Add support for O_MAYEXEC" "to enable to control script execution". >> What is not clear here? This seems well understood by other commenters. >> The documentation patch and the talks can also help. > > I'm guessing that passing O_MAYEXEC to open() requests the kernel > check for execute 'x' permissions (as well as read). Yes, but only with openat2(). > > Then kernel policy determines whether 'read' access is actually enough, > or whether 'x' access (possibly masked by mount permissions) is needed. > > If that is true, two lines say what is does. The "A simple system-wide security policy" paragraph introduce that, but I'll highlight it in the next cover letter. The most important point is to understand why it is required, before getting to how it will be implemented. > > Have you ever set a shell script permissions to --x--s--x ? > Ends up being executable by everyone except the owner! In this case the script is indeed executable but it can't be executed because the interpreter (i.e. the user) needs to be able to read the file. Of course, if the user has CAP_DAC_OVERRIDE (like the root user), read is still allowed. > Having the kernel pass all '#!' files to their interpreters > through an open fd might help security. This is interesting but it doesn't address the current issue: being able to have a consistent (script) executability system policy. Maybe its this point of view which wasn't clear enough? > In that case the user doesn't need read access to the file > in order to get an interpreter to process it. Yes, but this brings security issues, because the interpreter (i.e. the user) would then be able to read files without read permission. > (You'd need to stop strace showing the contents to actually > hide them.) It doesn't matter if the process is traced or not, the kernel handles impersonation scopes thanks to ptrace_may_access().
From: Mickaël Salaün <mic@digikod.net> > Sent: 07 May 2020 10:30 > On 07/05/2020 11:00, David Laight wrote: > > From: Mickaël Salaün > >> Sent: 07 May 2020 09:37 > > ... > >>> None of that description actually says what the patch actually does. > >> > >> "Add support for O_MAYEXEC" "to enable to control script execution". > >> What is not clear here? This seems well understood by other commenters. > >> The documentation patch and the talks can also help. > > > > I'm guessing that passing O_MAYEXEC to open() requests the kernel > > check for execute 'x' permissions (as well as read). > > Yes, but only with openat2(). It can't matter if the flag is ignored. It just means the kernel isn't enforcing the policy. If openat2() fail because the flag is unsupported then the application will need to retry without the flag. So if the user has any ability create executable files this is all pointless (from a security point of view). The user can either copy the file or copy in an interpreter that doesn't request O_MAYEXEC. It might stop accidental issues, but nothing malicious. > > Then kernel policy determines whether 'read' access is actually enough, > > or whether 'x' access (possibly masked by mount permissions) is needed. > > > > If that is true, two lines say what is does. > > The "A simple system-wide security policy" paragraph introduce that, but > I'll highlight it in the next cover letter. No it doesn't. It just says there is some kind of policy that some flags change. It doesn't say what is being checked for. > The most important point is > to understand why it is required, before getting to how it will be > implemented. But you don't say what is required. Just a load of buzzword ramblings. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 07/05/2020 11:44, David Laight wrote: > From: Mickaël Salaün <mic@digikod.net> >> Sent: 07 May 2020 10:30 >> On 07/05/2020 11:00, David Laight wrote: >>> From: Mickaël Salaün >>>> Sent: 07 May 2020 09:37 >>> ... >>>>> None of that description actually says what the patch actually does. >>>> >>>> "Add support for O_MAYEXEC" "to enable to control script execution". >>>> What is not clear here? This seems well understood by other commenters. >>>> The documentation patch and the talks can also help. >>> >>> I'm guessing that passing O_MAYEXEC to open() requests the kernel >>> check for execute 'x' permissions (as well as read). >> >> Yes, but only with openat2(). > > It can't matter if the flag is ignored. > It just means the kernel isn't enforcing the policy. > If openat2() fail because the flag is unsupported then > the application will need to retry without the flag. I don't get what you want to prove. Please read carefully the cover letter, the use case and the threat model. > > So if the user has any ability create executable files this > is all pointless (from a security point of view). > The user can either copy the file or copy in an interpreter > that doesn't request O_MAYEXEC.> > It might stop accidental issues, but nothing malicious. The execute permission (like the write permission) does not only depends on the permission set on files, but it also depends on the options/permission of their mount points, the MAC policy, etc. The initial use case to enforce O_MAYEXEC is to rely on the noexec mount option. If you want a consistent policy, you need to make one. Only dealing with file properties may not be enough. This is explain in the cover letter and the patches. If you allow all users to write and execute their files, then there is no point in enforcing anything with O_MAYEXEC. > >>> Then kernel policy determines whether 'read' access is actually enough, >>> or whether 'x' access (possibly masked by mount permissions) is needed. >>> >>> If that is true, two lines say what is does. >> >> The "A simple system-wide security policy" paragraph introduce that, but >> I'll highlight it in the next cover letter. > > No it doesn't. > It just says there is some kind of policy that some flags change. > It doesn't say what is being checked for. It said "the mount points or the file access rights". Please take a look at the documentation patch. > >> The most important point is >> to understand why it is required, before getting to how it will be >> implemented. > > But you don't say what is required. A consistent policy. Please take a look at the documentation patch which explains the remaining prerequisites. You can also take a look at the talks for further details. > Just a load of buzzword ramblings. It is a summary. Can you please suggest something better?
On Thu, May 7, 2020 at 4:38 PM Mickaël Salaün <mic@digikod.net> wrote: > > > On 07/05/2020 11:44, David Laight wrote: > > From: Mickaël Salaün <mic@digikod.net> > >> Sent: 07 May 2020 10:30 > >> On 07/05/2020 11:00, David Laight wrote: > >>> From: Mickaël Salaün > >>>> Sent: 07 May 2020 09:37 > >>> ... > >>>>> None of that description actually says what the patch actually does. > >>>> > >>>> "Add support for O_MAYEXEC" "to enable to control script execution". > >>>> What is not clear here? This seems well understood by other commenters. > >>>> The documentation patch and the talks can also help. > >>> > >>> I'm guessing that passing O_MAYEXEC to open() requests the kernel > >>> check for execute 'x' permissions (as well as read). > >> > >> Yes, but only with openat2(). > > > > It can't matter if the flag is ignored. > > It just means the kernel isn't enforcing the policy. > > If openat2() fail because the flag is unsupported then > > the application will need to retry without the flag. > > I don't get what you want to prove. Please read carefully the cover > letter, the use case and the threat model. > > > > > So if the user has any ability create executable files this > > is all pointless (from a security point of view). > > The user can either copy the file or copy in an interpreter > > that doesn't request O_MAYEXEC.> > > It might stop accidental issues, but nothing malicious. > > The execute permission (like the write permission) does not only depends > on the permission set on files, but it also depends on the > options/permission of their mount points, the MAC policy, etc. The > initial use case to enforce O_MAYEXEC is to rely on the noexec mount option. > > If you want a consistent policy, you need to make one. Only dealing with > file properties may not be enough. This is explain in the cover letter > and the patches. If you allow all users to write and execute their > files, then there is no point in enforcing anything with O_MAYEXEC. > > > > >>> Then kernel policy determines whether 'read' access is actually enough, > >>> or whether 'x' access (possibly masked by mount permissions) is needed. > >>> > >>> If that is true, two lines say what is does. > >> > >> The "A simple system-wide security policy" paragraph introduce that, but > >> I'll highlight it in the next cover letter. > > > > No it doesn't. > > It just says there is some kind of policy that some flags change. > > It doesn't say what is being checked for. > > It said "the mount points or the file access rights". Please take a look > at the documentation patch. > > > > >> The most important point is > >> to understand why it is required, before getting to how it will be > >> implemented. > > > > But you don't say what is required. > > A consistent policy. Please take a look at the documentation patch which > explains the remaining prerequisites. You can also take a look at the > talks for further details. > > > Just a load of buzzword ramblings. > > It is a summary. Can you please suggest something better? I can suggest something better ( I believe) Some time ago I proposed patch to IMA - Add suffix in IMA policy rule criteria It allows IMA to verify scripts, configuration files and even single file. It is very simple and does not depend on open flags. Mimi Zohar decided not to include this patch on the reason it tries to protect the file name. ( Why ??). https://lore.kernel.org/linux-integrity/20200330122434.GB28214@kl/
On Fri, 2020-05-08 at 10:15 +0300, Lev R. Oshvang . wrote: > I can suggest something better ( I believe) > Some time ago I proposed patch to IMA - Add suffix in IMA policy rule criteria > It allows IMA to verify scripts, configuration files and even single file. > It is very simple and does not depend on open flags. > Mimi Zohar decided not to include this patch on the reason it tries to > protect the file name. > ( Why ??). Your patch relies on the filename, but does nothing to protect it. Mimi