# Re: \[PATCH v14 1/3\] fs: Add trusted\_for(2) syscall implementation and related sysctl - List: linux-security-module - 3 messages, 3 authors - Page: https://ratatoskr.run/linux-security-module/2021/10/215667/t ## Re: \[PATCH v14 1/3\] fs: Add trusted\_for(2) syscall implementation and related sysctl - From: Florian Weimer \ - Date: 2021-10-10 14:21:35 - Message: https://ratatoskr.run/linux-security-module/2021/10/215667.md ```text * 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. ``` ## Re: \[PATCH v14 1/3\] fs: Add trusted\_for(2) syscall implementation and related sysctl - From: Mickaël Salaün \ - Date: 2021-10-11 08:26:16 - Message: https://ratatoskr.run/linux-security-module/2021/10/215684.md ```text 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. ``` ## Re: \[PATCH v14 1/3\] fs: Add trusted\_for(2) syscall implementation and related sysctl - From: Mimi Zohar \ - Date: 2021-10-11 15:21:57 - Message: https://ratatoskr.run/linux-security-module/2021/10/215700.md ```text 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 > > > 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 ```