* 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.
On 10/10/2021 16:10, Florian Weimer wrote:
* Mickaël Salaün:
quoted
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.
Hi Florian,
On Sun, 2021-10-10 at 16:10 +0200, Florian Weimer wrote:
* Mickaël Salaün:
quoted
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