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:

quoted

On Wed, Jul 17, 2024 at 3:01 AM Mickaël Salaün [off-list ref]
wrote:

quoted

On Tue, Jul 16, 2024 at 11:33:55PM -0700, Jeff Xu wrote:

[...]

quoted

quoted

quoted

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