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.
