Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Oct 2021 11:20:02 -0400
From: Mimi Zohar <>
To: Florian Weimer <>,
        Mickaël Salaün
Cc: Al Viro <>,
        Andrew Morton
        Aleksa Sarai <>, Andy
 Lutomirski <>,
        Arnd Bergmann <>,
 Schaufler <>,
        Christian Brauner
        Christian Heimes <>,
        Deven Bowers <>,
        Dmitry Vyukov
        Eric Biggers <>,
        Eric Chiang
        Geert Uytterhoeven <>,
 Morris <>, Jan Kara <>,
        Jann Horn
 <>, Jonathan Corbet <>,
        Kees Cook
        Lakshmi Ramasubramanian
        "Madhavan T . Venkataraman"
        Matthew Garrett <>,
 Wilcox <>,
        Miklos Szeredi <>,
 Moore <>,
        Philippe Trébuchet
        Scott Shell <>, Shuah Khan <>,
        Steve Dower <>, Steve
 Grubb <>,
        Thibaut Sautereau
        Vincent Strubel
        Mickaël Salaün
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
>   <>
> 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?


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.