Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Oct 2021 10:26:58 +0200
From: Mickaël Salaün <>
To: Florian Weimer <>
Cc: Al Viro <>,
 Andrew Morton <>, Aleksa Sarai <>,
 Andy Lutomirski <>, Arnd Bergmann <>,
 Casey Schaufler <>,
 Christian Brauner <>,
 Christian Heimes <>,
 Deven Bowers <>,
 Dmitry Vyukov <>, Eric Biggers <>,
 Eric Chiang <>,
 Geert Uytterhoeven <>, James Morris <>,
 Jan Kara <>, Jann Horn <>,
 Jonathan Corbet <>, Kees Cook <>,
 Lakshmi Ramasubramanian <>,
 "Madhavan T . Venkataraman" <>,
 Matthew Garrett <>, Matthew Wilcox <>,
 Miklos Szeredi <>, Mimi Zohar <>,
 Paul Moore <>,
 Philippe Trébuchet <>,
 Scott Shell <>, Shuah Khan <>,
 Steve Dower <>, Steve Grubb <>,
 Thibaut Sautereau <>,
 Vincent Strubel <>,,,,,,,
 Mickaël Salaün <>
Subject: Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and
 related sysctl

On 10/10/2021 16:10, Florian Weimer wrote:
> * Mickaël Salaün:
>> Being able to restrict execution also enables to protect the kernel by
>> restricting arbitrary syscalls that an attacker could perform with a
>> crafted binary or certain script languages.  It also improves multilevel
>> isolation by reducing the ability of an attacker to use side channels
>> with specific code.  These restrictions can natively be enforced for ELF
>> binaries (with the noexec mount option) but require this kernel
>> extension to properly handle scripts (e.g. Python, Perl).  To get a
>> consistent execution policy, additional memory restrictions should also
>> be enforced (e.g. thanks to SELinux).
> One example I have come across recently is that code which can be
> safely loaded as a Perl module is definitely not a no-op as a shell
> script: it downloads code and executes it, apparently over an
> untrusted network connection and without signature checking.
> Maybe in the IMA world, the expectation is that such ambiguous code
> would not be signed in the first place, but general-purpose
> distributions are heading in a different direction with
> across-the-board signing:
>   Signed RPM Contents
>   <>
> So I wonder if we need additional context information for a potential
> LSM to identify the intended use case.

This is an interesting use case. I think such policy enforcement could
be done either with an existing LSM (e.g. IMA) or a new one (e.g. IPE),
but it could also partially be enforced by the script interpreter. The
kernel should have enough context: interpreter process (which could be
dedicated to a specific usage) and the opened script file, or we could
add a new usage flag to the trusted_for syscall if that makes sense.
Either way, this doesn't seem to be an issue for the current patch series.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.