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

[Mickaël Salaün]

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
>   <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.
> 

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.