Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl

[Mimi Zohar <zohar@linux.ibm.com>]

Hi Florian,

On Sun, 2021-10-10 at 16:10 +0200, 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:

Automatically signing code is at least the first step in the right
direction of only executing code with known provenance.  Perhaps future
work would address the code signing granularity.

> 
>   Signed RPM Contents
>   <https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents>
> 
> So I wonder if we need additional context information for a potential
> LSM to identify the intended use case.

My first thoughts were an enumeration UNSIGNED_DOWNLOADED_CODE or maybe
even UNTRUSTED_DOWNLOADED_CODE, but that doesn't seem very
helpful.  What type of context information were you thinking about?

Mimi