[v12,0/3] Add trusted_for(2) (was O_MAYEXEC)

Message

Mickaël Salaün Dec. 3, 2020, 5:31 p.m. UTC

Hi,

This patch series is a rebase on v5.10-rc6 .  Can you please consider to
merge this into the tree?

Overview
========

The final goal of this patch series is to enable the kernel to be a
global policy manager by entrusting processes with access control at
their level.  To reach this goal, two complementary parts are required:
* user space needs to be able to know if it can trust some file
  descriptor content for a specific usage;
* and the kernel needs to make available some part of the policy
  configured by the system administrator.

Primary goal of trusted_for(2)
==============================

This new syscall enables user space to ask the kernel: is this file
descriptor's content trusted to be used for this purpose?  The set of
usage currently only contains "execution", but other may follow (e.g.
"configuration", "sensitive_data").  If the kernel identifies the file
descriptor as trustworthy for this usage, user space should then take
this information into account.  The "execution" usage means that the
content of the file descriptor is trusted according to the system policy
to be executed by user space, which means that it interprets the content
or (try to) maps it as executable memory.

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.

It is important to note that this can only enable to extend access
control managed by the kernel.  Hence it enables current access control
mechanism to be extended and become a superset of what they can
currently control.  Indeed, the security policy could also be delegated
to an LSM, either a MAC system or an integrity system.  For instance,
this is required to close 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 magic-links [2], SGX integration
[3], bpffs [4].

Complementary W^X protections can be brought by SELinux, IPE [5] and
trampfd [6].

Prerequisite of its use
=======================

User space needs to adapt to take advantage of this new feature.  For
example, the PEP 578 [7] (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
without -c, stdin piping of code) are on their way [8].

Examples
========

The initial idea comes from CLIP OS 4 and the original implementation
has been used for more than 12 years:
https://github.com/clipos-archive/clipos4_doc
Chrome OS has a similar approach:
https://chromium.googlesource.com/chromiumos/docs/+/master/security/noexec_shell_scripts.md

Userland patches can be found here:
https://github.com/clipos-archive/clipos4_portage-overlay/search?q=O_MAYEXEC
Actually, there is more than the O_MAYEXEC changes (which matches this search)
e.g., to prevent Python interactive execution. There are patches for
Bash, Wine, Java (Icedtea), Busybox's ash, Perl and Python. There are
also some related patches which do not directly rely on O_MAYEXEC but
which restrict the use of browser plugins and extensions, which may be
seen as scripts too:
https://github.com/clipos-archive/clipos4_portage-overlay/tree/master/www-client

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
See also a first LWN article about O_MAYEXEC and a new one about
trusted_for(2) and its background:
* https://lwn.net/Articles/820000/
* https://lwn.net/Articles/832959/

This patch series can be applied on top of v5.10-rc6 .  This can be
tested with CONFIG_SYSCTL.  I would really appreciate constructive
comments on this patch series.

Previous series:
https://lore.kernel.org/lkml/[e-mail]/

[1] https://lore.kernel.org/lkml/[e-mail]/
[2] https://lore.kernel.org/lkml/[e-mail]/
[3] https://lore.kernel.org/lkml/CALCETrVovr8XNZSroey7pHF46O=kj_c5D9K8h=[e-mail]/
[4] https://lore.kernel.org/lkml/[e-mail]/
[5] https://lore.kernel.org/lkml/[e-mail]/
[6] https://lore.kernel.org/lkml/[e-mail]/
[7] https://www.python.org/dev/peps/pep-0578/
[8] https://lore.kernel.org/lkml/[e-mail]/

Regards,

Mickaël Salaün (3):
  fs: Add trusted_for(2) syscall implementation and related sysctl
  arch: Wire up trusted_for(2)
  selftest/interpreter: Add tests for trusted_for(2) policies

 Documentation/admin-guide/sysctl/fs.rst       |  50 +++
 arch/alpha/kernel/syscalls/syscall.tbl        |   1 +
 arch/arm/tools/syscall.tbl                    |   1 +
 arch/arm64/include/asm/unistd.h               |   2 +-
 arch/arm64/include/asm/unistd32.h             |   2 +
 arch/ia64/kernel/syscalls/syscall.tbl         |   1 +
 arch/m68k/kernel/syscalls/syscall.tbl         |   1 +
 arch/microblaze/kernel/syscalls/syscall.tbl   |   1 +
 arch/mips/kernel/syscalls/syscall_n32.tbl     |   1 +
 arch/mips/kernel/syscalls/syscall_n64.tbl     |   1 +
 arch/mips/kernel/syscalls/syscall_o32.tbl     |   1 +
 arch/parisc/kernel/syscalls/syscall.tbl       |   1 +
 arch/powerpc/kernel/syscalls/syscall.tbl      |   1 +
 arch/s390/kernel/syscalls/syscall.tbl         |   1 +
 arch/sh/kernel/syscalls/syscall.tbl           |   1 +
 arch/sparc/kernel/syscalls/syscall.tbl        |   1 +
 arch/x86/entry/syscalls/syscall_32.tbl        |   1 +
 arch/x86/entry/syscalls/syscall_64.tbl        |   1 +
 arch/xtensa/kernel/syscalls/syscall.tbl       |   1 +
 fs/open.c                                     |  77 ++++
 include/linux/fs.h                            |   1 +
 include/linux/syscalls.h                      |   2 +
 include/uapi/asm-generic/unistd.h             |   4 +-
 include/uapi/linux/trusted-for.h              |  18 +
 kernel/sysctl.c                               |  12 +-
 tools/testing/selftests/Makefile              |   1 +
 .../testing/selftests/interpreter/.gitignore  |   2 +
 tools/testing/selftests/interpreter/Makefile  |  21 +
 tools/testing/selftests/interpreter/config    |   1 +
 .../selftests/interpreter/trust_policy_test.c | 362 ++++++++++++++++++
 30 files changed, 567 insertions(+), 4 deletions(-)
 create mode 100644 include/uapi/linux/trusted-for.h
 create mode 100644 tools/testing/selftests/interpreter/.gitignore
 create mode 100644 tools/testing/selftests/interpreter/Makefile
 create mode 100644 tools/testing/selftests/interpreter/config
 create mode 100644 tools/testing/selftests/interpreter/trust_policy_test.c


base-commit: b65054597872ce3aefbc6a666385eabdf9e288da

Comments

bauen1 April 9, 2021, 4:26 p.m. UTC | #1

Hello,

As a user of SELinux I'm quite interested in the trusted_for / O_MAYEXEC changes in the kernel and userspace.
However the last activity on this patch seems to be this email from 2020-12-03 with no replies, so what is the status of this patchset or is there something that I'm missing ?

https://patchwork.kernel.org/project/linux-security-module/list/?series=395617

https://lore.kernel.org/linux-security-module/[e-mail]/

Mickaël Salaün April 9, 2021, 5:15 p.m. UTC | #2

Hi,

There was no new reviews, probably because the FS maintainers were busy,
and I was focused on Landlock (which is now in -next), but I plan to
send a new patch series for trusted_for(2) soon.

Thanks for letting know your interest,
 Mickaël


On 09/04/2021 18:26, bauen1 wrote:
> Hello,
> 
> As a user of SELinux I'm quite interested in the trusted_for / O_MAYEXEC changes in the kernel and userspace.
> However the last activity on this patch seems to be this email from 2020-12-03 with no replies, so what is the status of this patchset or is there something that I'm missing ?
> 
> https://patchwork.kernel.org/project/linux-security-module/list/?series=395617
> 
> https://lore.kernel.org/linux-security-module/[e-mail]/
> 
>

Kees Cook Oct. 6, 2021, 10:03 p.m. UTC | #3

On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote:
> There was no new reviews, probably because the FS maintainers were busy,
> and I was focused on Landlock (which is now in -next), but I plan to
> send a new patch series for trusted_for(2) soon.

Hi!

Did this ever happen? It looks like it's in good shape, and I think it's
a nice building block for userspace to have. Are you able to rebase and
re-send this?

I've tended to aim these things at akpm if Al gets busy. (And since
you've had past review from Al, that should be hopefully sufficient.)

Thanks for chasing this!

-Kees

Mickaël Salaün Oct. 7, 2021, 6:29 p.m. UTC | #4

On 07/10/2021 00:03, Kees Cook wrote:
> On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote:
>> There was no new reviews, probably because the FS maintainers were busy,
>> and I was focused on Landlock (which is now in -next), but I plan to
>> send a new patch series for trusted_for(2) soon.
> 
> Hi!
> 
> Did this ever happen? It looks like it's in good shape, and I think it's
> a nice building block for userspace to have. Are you able to rebase and
> re-send this?

I just sent it:
https://lore.kernel.org/all/[e-mail]/

Some Signed-off-by would be appreciated. :)

> 
> I've tended to aim these things at akpm if Al gets busy. (And since
> you've had past review from Al, that should be hopefully sufficient.)
> 
> Thanks for chasing this!
> 
> -Kees
>

Mimi Zohar Oct. 7, 2021, 6:37 p.m. UTC | #5

On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote:
> On 07/10/2021 00:03, Kees Cook wrote:
> > On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote:
> >> There was no new reviews, probably because the FS maintainers were busy,
> >> and I was focused on Landlock (which is now in -next), but I plan to
> >> send a new patch series for trusted_for(2) soon.
> > 
> > Hi!
> > 
> > Did this ever happen? It looks like it's in good shape, and I think it's
> > a nice building block for userspace to have. Are you able to rebase and
> > re-send this?
> 
> I just sent it:
> https://lore.kernel.org/all/[e-mail]/
> 
> Some Signed-off-by would be appreciated. :)
> 

From the cover letter, 

It is important to note that this can only enable to extend access
control managed by the kernel.  Hence it enables current access control
mechanism to be extended and become a superset of what they can
currently control.  Indeed, the security policy could also be delegated
to an LSM, either a MAC system or an integrity system.  For instance,
this is required to close 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 magic-links [2], SGX integration
[3], bpffs [4].

From a quick review of the code, I don't see a new security hook being
defined to cover these use cases.

thanks,

Mimi

> > 
> > I've tended to aim these things at akpm if Al gets busy. (And since
> > you've had past review from Al, that should be hopefully sufficient.)
> > 
> > Thanks for chasing this!
> > 
> > -Kees
> >

Mickaël Salaün Oct. 7, 2021, 7 p.m. UTC | #6

On 07/10/2021 20:37, Mimi Zohar wrote:
> On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote:
>> On 07/10/2021 00:03, Kees Cook wrote:
>>> On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote:
>>>> There was no new reviews, probably because the FS maintainers were busy,
>>>> and I was focused on Landlock (which is now in -next), but I plan to
>>>> send a new patch series for trusted_for(2) soon.
>>>
>>> Hi!
>>>
>>> Did this ever happen? It looks like it's in good shape, and I think it's
>>> a nice building block for userspace to have. Are you able to rebase and
>>> re-send this?
>>
>> I just sent it:
>> https://lore.kernel.org/all/[e-mail]/
>>
>> Some Signed-off-by would be appreciated. :)
>>
> 
>>From the cover letter, 
> 
> It is important to note that this can only enable to extend access
> control managed by the kernel.  Hence it enables current access control
> mechanism to be extended and become a superset of what they can
> currently control.  Indeed, the security policy could also be delegated
> to an LSM, either a MAC system or an integrity system.  For instance,
> this is required to close 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 magic-links [2], SGX integration
> [3], bpffs [4].
> 
>>From a quick review of the code, I don't see a new security hook being
> defined to cover these use cases.

Indeed, there is no new hook because it would require to implement it
with a current LSM. This first step is a standalone implementation that
is useful as-is but open the way to add a new LSM hook in this new
syscall. That would be a second step for any LSM developer to implement
if interested.

> 
> thanks,
> 
> Mimi
> 
>>>
>>> I've tended to aim these things at akpm if Al gets busy. (And since
>>> you've had past review from Al, that should be hopefully sufficient.)
>>>
>>> Thanks for chasing this!
>>>
>>> -Kees
>>>
> 
>