linux-kernel - Re: [PATCH] ima: instantiate the bprm_creds_for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <f588fffdb27b28531e900e59cc17182617726b59.camel@linux.ibm.com>
Date: Tue, 03 Dec 2024 11:03:08 -0500
From: Mimi Zohar <zohar@...ux.ibm.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: linux-integrity@...r.kernel.org, roberto.sassu@...wei.com,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
        audit@...r.kernel.org, Paul Moore <paul@...l-moore.com>,
        Jeff Xu
	 <jeffxu@...omium.org>, Kees Cook <kees@...nel.org>
Subject: Re: [PATCH] ima: instantiate the bprm_creds_for_exec() hook

On Tue, 2024-12-03 at 12:53 +0100, Mickaël Salaün wrote:
> On Mon, Dec 02, 2024 at 02:40:35PM -0500, Mimi Zohar wrote:
> > On Fri, 2024-11-29 at 12:06 +0100, Mickaël Salaün wrote:
> > > For reference, here is the base patch series:
> > > https://lore.kernel.org/all/20241112191858.162021-1-mic@digikod.net/
> > > 
> > > CCing audit@
> > > 
> > > On Wed, Nov 27, 2024 at 04:02:34PM -0500, Mimi Zohar wrote:
> > > > Like direct file execution (e.g. ./script.sh), indirect file execution
> > > > (e.g. sh script.sh) needs to be measured and appraised.  Instantiate
> > > > the new security_bprm_creds_for_exec() hook to measure and verify the
> > > > indirect file's integrity.  Unlike direct file execution, indirect file
> > > > execution integrity is optionally enforced by the interpreter.
> > > > 
> > > > Update the audit messages to differentiate between kernel and userspace
> > > > enforced integrity.
> > > 
> > > I'm not sure to see the full picture.  What is the difference between
> > > execveat() calls and execveat() + AT_EXECVE_CHECK calls?  Both are from
> > > user space, the only difference is that the first can lead to a full
> > > execution, but the intent is the same.
> > 
> > We do want the full execution in order to measure/appraise/audit both the direct
> > file execution (e.g. ./script.sh) and the interpreter (e.g. #!/usr/bin/bash)
> > specified.
> 
> Yes, but I was wondering about the difference in the log messages.  In
> both cases the script is checked, but only without AT_EXECVE_CHECK its
> "dependencies" (e.g. script interpreter) are checked.  I guess it could
> be useful to differenciate those but I wanted to make sure we were on
> the same page.

By "those" I assume you're referring to with/without AT_EXECVE_CHECK and not the
missing "dependencies".

In both cases the integrity of the script is being checked, but in one case the
integrity is being enforced by the kernel, while in the other case userspace may
enforce integrity.  The audit message should different between these two cases.

Mimi