Date: Mon, 11 Oct 2021 11:20:02 -0400 From: Mimi Zohar <zohar@...ux.ibm.com> To: Florian Weimer <fw@...eb.enyo.de>, Mickaël Salaün <mic@...ikod.net> Cc: Al Viro <viro@...iv.linux.org.uk>, Andrew Morton <akpm@...ux-foundation.org>, Aleksa Sarai <cyphar@...har.com>, Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Casey Schaufler <casey@...aufler-ca.com>, Christian Brauner <christian.brauner@...ntu.com>, Christian Heimes <christian@...hon.org>, Deven Bowers <deven.desai@...ux.microsoft.com>, Dmitry Vyukov <dvyukov@...gle.com>, Eric Biggers <ebiggers@...nel.org>, Eric Chiang <ericchiang@...gle.com>, Geert Uytterhoeven <geert@...ux-m68k.org>, James Morris <jmorris@...ei.org>, Jan Kara <jack@...e.cz>, Jann Horn <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>, Lakshmi Ramasubramanian <nramas@...ux.microsoft.com>, "Madhavan T . Venkataraman" <madvenka@...ux.microsoft.com>, Matthew Garrett <mjg59@...gle.com>, Matthew Wilcox <willy@...radead.org>, Miklos Szeredi <mszeredi@...hat.com>, Paul Moore <paul@...l-moore.com>, Philippe Trébuchet <philippe.trebuchet@....gouv.fr>, Scott Shell <scottsh@...rosoft.com>, Shuah Khan <shuah@...nel.org>, Steve Dower <steve.dower@...hon.org>, Steve Grubb <sgrubb@...hat.com>, Thibaut Sautereau <thibaut.sautereau@....gouv.fr>, Vincent Strubel <vincent.strubel@....gouv.fr>, kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org, Mickaël Salaün <mic@...ux.microsoft.com> Subject: Re: [PATCH v14 1/3] fs: Add trusted_for(2) syscall implementation and related sysctl 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.