[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 01 Dec 2021 08:14:54 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Mickaël Salaün <mic@...ikod.net>,
Florian Weimer
<fweimer@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Andrew Morton
<akpm@...ux-foundation.org>,
Alejandro Colomar <alx.manpages@...il.com>,
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>,
Yin Fengwei <fengwei.yin@...el.com>,
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
Subject: Re: [PATCH v17 0/3] Add trusted_for(2) (was O_MAYEXEC)
On Wed, 2021-12-01 at 10:23 +0100, Mickaël Salaün wrote:
> On 30/11/2021 21:27, Florian Weimer wrote:
> > * Mickaël Salaün:
> >
> >> Primary goal of trusted_for(2)
> >> ==============================
> >>
> >> This new syscall enables user space to ask the kernel: is this file
> >> descriptor's content trusted to be used for this purpose? The set of
> >> usage currently only contains execution, but other may follow (e.g.
> >> configuration, sensitive data). If the kernel identifies the file
> >> descriptor as trustworthy for this usage, user space should then take
> >> this information into account. The "execution" usage means that the
> >> content of the file descriptor is trusted according to the system policy
> >> to be executed by user space, which means that it interprets the content
> >> or (try to) maps it as executable memory.
> >
> > I sketched my ideas about “IMA gadgets” here:
> >
> > IMA gadgets
> > <https://www.openwall.com/lists/oss-security/2021/11/30/1>
> >
> > I still don't think the proposed trusted_for interface is sufficient.
> > The example I gave is a Perl module that does nothing (on its own) when
> > loaded as a Perl module (although you probably don't want to sign it
> > anyway, given what it implements), but triggers an unwanted action when
> > sourced (using .) as a shell script.
>
> The fact that IMA doesn't cover all metadata, file names nor the file
> hierarchies is well known and the solution can be implemented with
> dm-verity (which has its own drawbacks).
Thanks, Mickaël, for responding. I'll go even farther and say that IMA
wasn't ever meant to protect file metadata. Another option is EVM,
which addresses some, but not all of the issues.
thanks,
Mimi
>
> trusted_for is a tool for interpreters to enforce a security policy
> centralized by the kernel. The kind of file confusion attacks you are
> talking about should be addressed by a system policy. If the mount point
> options are not enough to express such policy, then we need to rely on
> IMA, SELinux or IPE to reduce the scope of legitimate mapping between
> scripts and interpreters.
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.
