[v5,0/6] Add support for O_MAYEXEC
mbox series

Message ID 20200505153156.925111-1-mic@digikod.net
Headers show
Series
  • Add support for O_MAYEXEC
Related show

Message

Mickaël Salaün May 5, 2020, 3:31 p.m. UTC
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/


[1] https://lore.kernel.org/lkml/1544647356.4028.105.camel@linux.ibm.com/
[2] https://lore.kernel.org/lkml/20190904201933.10736-6-cyphar@cyphar.com/
[3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=z2T_cNrpvMig@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CALCETrVeZ0eufFXwfhtaG_j+AdvbzEWE0M3wjXMWVEO7pj+xkw@mail.gmail.com/
[5] https://lore.kernel.org/lkml/20200406221439.1469862-12-deven.desai@linux.microsoft.com/
[6] https://www.python.org/dev/peps/pep-0578/

Regards,

Mickaël Salaün (5):
  fs: Add support for an O_MAYEXEC flag on openat2(2)
  fs: Add a MAY_EXECMOUNT flag to infer the noexec mount property
  fs: Enable to enforce noexec mounts or file exec through O_MAYEXEC
  selftest/openat2: Add tests for O_MAYEXEC enforcing
  doc: Add documentation for the fs.open_mayexec_enforce sysctl

Mimi Zohar (1):
  ima: add policy support for the new file open MAY_OPENEXEC flag

 Documentation/ABI/testing/ima_policy          |   2 +-
 Documentation/admin-guide/sysctl/fs.rst       |  44 +++
 fs/fcntl.c                                    |   2 +-
 fs/namei.c                                    |  89 ++++-
 fs/open.c                                     |   8 +
 include/linux/fcntl.h                         |   2 +-
 include/linux/fs.h                            |   9 +
 include/uapi/asm-generic/fcntl.h              |   7 +
 kernel/sysctl.c                               |   9 +
 security/Kconfig                              |  26 ++
 security/integrity/ima/ima_main.c             |   3 +-
 security/integrity/ima/ima_policy.c           |  15 +-
 tools/testing/selftests/kselftest_harness.h   |   3 +
 tools/testing/selftests/openat2/Makefile      |   3 +-
 tools/testing/selftests/openat2/config        |   1 +
 tools/testing/selftests/openat2/helpers.h     |   1 +
 .../testing/selftests/openat2/omayexec_test.c | 330 ++++++++++++++++++
 17 files changed, 544 insertions(+), 10 deletions(-)
 create mode 100644 tools/testing/selftests/openat2/config
 create mode 100644 tools/testing/selftests/openat2/omayexec_test.c

Comments

Mickaël Salaün May 5, 2020, 3:36 p.m. UTC | #1
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/
Lev R. Oshvang . May 6, 2020, 1:58 p.m. UTC | #2
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
Aleksa Sarai May 6, 2020, 3:41 p.m. UTC | #3
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
David Laight May 7, 2020, 8:05 a.m. UTC | #4
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)
Mickaël Salaün May 7, 2020, 8:30 a.m. UTC | #5
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
>
Mickaël Salaün May 7, 2020, 8:36 a.m. UTC | #6
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.
David Laight May 7, 2020, 9 a.m. UTC | #7
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)
Mickaël Salaün May 7, 2020, 9:30 a.m. UTC | #8
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().
David Laight May 7, 2020, 9:44 a.m. UTC | #9
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)
Mickaël Salaün May 7, 2020, 1:38 p.m. UTC | #10
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?
Lev R. Oshvang . May 8, 2020, 7:15 a.m. UTC | #11
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/
Mimi Zohar May 8, 2020, 2:01 p.m. UTC | #12
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