[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <539086ce33ed6417dd1ada1c8f593fc0edeb8f73.camel@linux.ibm.com>
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.
