Message-ID: <544d08f5b55a0fbb1dc883bce6cf94c78cf46e42.camel@HansenPartnership.com>
Date: Thu, 18 Jul 2024 09:03:36 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Mickaël Salaün <mic@...ikod.net>, Jeff Xu
	 <jeffxu@...gle.com>
Cc: Al Viro <viro@...iv.linux.org.uk>, Christian Brauner
 <brauner@...nel.org>,  Kees Cook <keescook@...omium.org>, Linus Torvalds
 <torvalds@...ux-foundation.org>, Paul Moore <paul@...l-moore.com>, Theodore
 Ts'o <tytso@....edu>, Alejandro Colomar <alx@...nel.org>, Aleksa Sarai
 <cyphar@...har.com>, Andrew Morton <akpm@...ux-foundation.org>, Andy
 Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Casey
 Schaufler <casey@...aufler-ca.com>, Christian Heimes
 <christian@...hon.org>, Dmitry Vyukov <dvyukov@...gle.com>, Eric Biggers
 <ebiggers@...nel.org>, Eric Chiang <ericchiang@...gle.com>, Fan Wu
 <wufan@...ux.microsoft.com>, Florian Weimer <fweimer@...hat.com>, Geert
 Uytterhoeven <geert@...ux-m68k.org>, James Morris
 <jamorris@...ux.microsoft.com>, Jan Kara <jack@...e.cz>,  Jann Horn
 <jannh@...gle.com>, Jonathan Corbet <corbet@....net>, Jordan R Abrahams
 <ajordanr@...gle.com>,  Lakshmi Ramasubramanian
 <nramas@...ux.microsoft.com>, Luca Boccassi <bluca@...ian.org>, Luis
 Chamberlain <mcgrof@...nel.org>,  "Madhavan T . Venkataraman"
 <madvenka@...ux.microsoft.com>, Matt Bobrowski <mattbobrowski@...gle.com>, 
 Matthew Garrett <mjg59@...f.ucam.org>, Matthew Wilcox
 <willy@...radead.org>, Miklos Szeredi <mszeredi@...hat.com>,  Mimi Zohar
 <zohar@...ux.ibm.com>, Nicolas Bouchinet <nicolas.bouchinet@....gouv.fr>,
 Scott Shell <scottsh@...rosoft.com>, Shuah Khan <shuah@...nel.org>, Stephen
 Rothwell <sfr@...b.auug.org.au>, Steve Dower <steve.dower@...hon.org>,
 Steve Grubb <sgrubb@...hat.com>, Thibaut Sautereau
 <thibaut.sautereau@....gouv.fr>,  Vincent Strubel
 <vincent.strubel@....gouv.fr>, Xiaoming Ni <nixiaoming@...wei.com>, 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, Elliott Hughes <enh@...gle.com>
Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2)

On Thu, 2024-07-18 at 14:24 +0200, Mickaël Salaün wrote:
> On Wed, Jul 17, 2024 at 07:08:17PM -0700, Jeff Xu wrote:
> > On Wed, Jul 17, 2024 at 3:01 AM Mickaël Salaün <mic@...ikod.net>
> > wrote:
> > > On Tue, Jul 16, 2024 at 11:33:55PM -0700, Jeff Xu wrote:
[...]
> > > > I'm still thinking  execveat(AT_CHECK) vs faccessat(AT_CHECK)
> > > > in different use cases:
> > > > 
> > > > execveat clearly has less code change, but that also means: we
> > > > can't add logic specific to exec (i.e. logic that can't be
> > > > applied to config) for this part (from do_execveat_common to
> > > > security_bprm_creds_for_exec) in future.  This would require
> > > > some agreement/sign-off, I'm not sure from whom.
> > > 
> > > I'm not sure to follow. We could still add new flags, but for now
> > > I don't see use cases.  This patch series is not meant to handle
> > > all possible "trust checks", only executable code, which makes
> > > sense for the kernel.
> > > 
> > I guess the "configfile" discussion is where I get confused, at one
> > point, I think this would become a generic "trust checks" api for
> > everything related to "generating executable code", e.g.
> > javascript, java code, and more. We will want to clearly define the
> > scope of execveat(AT_CHECK)
> 
> The line between data and code is blurry.  For instance, a
> configuration file can impact the execution flow of a program.  So,
> where to draw the line?

Having a way to have config files part of the trusted envelope, either
by signing or measurement would be really useful.  The current standard
distro IMA deployment is signed executables, but not signed config
because it's hard to construct a policy that doesn't force the signing
of too many extraneous files (and files which might change often).

> It might makes sense to follow the kernel and interpreter semantic:
> if a file can be executed by the kernel (e.g. ELF binary, file
> containing a shebang, or just configured with binfmt_misc), then this
> should be considered as executable code.  This applies to Bash,
> Python, Javascript, NodeJS, PE, PHP...  However, we can also make a
> picture executable with binfmt_misc.  So, again, where to draw the
> line?

Possibly by making open for config an indication executables can give?
I'm not advocating doing it in this patch, but if we had an open for
config indication, the LSMs could do much finer grained policy,
especially if they knew which executable was trying to open the config
file.  It would allow things like an IMA policy saying if a signed
executable is opening a config file, then that file must also be
signed.

James

Powered by blists - more mailing lists