From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB1EDC369A2 for ; Fri, 11 Apr 2025 22:14:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81D73680030; Fri, 11 Apr 2025 18:14:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 756C0680024; Fri, 11 Apr 2025 18:14:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D291680030; Fri, 11 Apr 2025 18:14:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 3CB16680024 for ; Fri, 11 Apr 2025 18:14:22 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B1C3D160949 for ; Fri, 11 Apr 2025 22:14:22 +0000 (UTC) X-FDA: 83323167564.12.B87C2A5 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) by imf16.hostedemail.com (Postfix) with ESMTP id 6EAF5180004 for ; Fri, 11 Apr 2025 22:14:20 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=ZESHHsfC; spf=pass (imf16.hostedemail.com: domain of paul@paul-moore.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744409660; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=p+m7hz6r5/ApjZEveg5QQkULfTfewkyo7s8/B03DRoo=; b=rbUTnlZ9mkI0F+SrbDmRZ1CV6AfpOheHGWD389urkNGg58YqQslo5vZCd2ASrbFmbBsWba XnWv5whlsJ0s+d38TxfqA9di5OBGpLE2UuEP3s+pW+7LEYUxLZxuA6eVdEWYZVlL+iHEt7 sN8NDiTYhSIiqB7nLzE8gVQglT/q9kY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=paul-moore.com header.s=google header.b=ZESHHsfC; spf=pass (imf16.hostedemail.com: domain of paul@paul-moore.com designates 209.85.128.182 as permitted sender) smtp.mailfrom=paul@paul-moore.com; dmarc=pass (policy=none) header.from=paul-moore.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744409660; a=rsa-sha256; cv=none; b=1pyM3ZxWDUUVvGZWX790Fd0q+VZcTpn+3b4OkPzenEHUh73Np+y8csaYKbqY8e3CXl1mOX xCM0OcUCu9n8+Nf37Y9cn5ScxZ869h1ysDma5q+gk1zeAlnWus3wLVAvDyEjxN/Pa4/7jY VLueI0ZkfO4JU8ivwavmGgHqmqMRjOc= Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-6f6ca9a3425so31228277b3.2 for ; Fri, 11 Apr 2025 15:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore.com; s=google; t=1744409659; x=1745014459; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=p+m7hz6r5/ApjZEveg5QQkULfTfewkyo7s8/B03DRoo=; b=ZESHHsfCB3wRx9smAr/bmpMOpLfZKC+cUhmwCe2SbT7ReLdHp5Ch87F9fHzrmpL67Y ldw+YPiM9i2w1RBaqCrSJoTmSUkZW3OxxDz4TlfF9wINRsAVj+Bw+VGRGsafobf9t3Di sdSx2M8L/iaTEMtpoGnAv5PYCJ94H3cUAP3i2kkVKZtCXgqLtwxxbNoPoB0vQpInLivg eAa9YIY041exlDQvDYX9RXK5CXGAP+ua1diKe2UYN/AIcbnxHQRLp+ufG+fnvghg7wsb TinU86PZgcWXwRGygmy0Cpcg3FNqTlHFYqxeyCYyfzXMSx1f7iPnonP746NHYk+ildMA Rs2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744409659; x=1745014459; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p+m7hz6r5/ApjZEveg5QQkULfTfewkyo7s8/B03DRoo=; b=rlgPXe19q9sLSKoZ/RkxzLZyor1vy2faAjmrVxzdYAmYccSvyPVQcVAlNizIWXBaqu cGIArGd5n+9R4oEyFFv8TCm4q8toWMoGuJ4UdBvG0Ye25btmaUioLoObe9LatnJvUw+Q s2HVsNFZmVL5S2BNA0hLI69POm9FK9ACQ3xFUGgX09GeYLXR0zeeDS/0nktgm1FCUaA8 zIaYA84ch59n6kTlDHrcpf9ZD9lPNlqgCCzL2yV5uzJTwK6vuvj+t5efLQZHFZTFRl00 C+W1jkROR9O7126pno+YuTlSNPdbQgwWx6Ylsq6yOewOgOIVbrj4eAeMUqzEulGPcWuE Nbbg== X-Forwarded-Encrypted: i=1; AJvYcCVSS6Ya7ujCPhdOuz+TOoHoW1bh8O4W0Vs/3KUMUrURVMSabUdcN46pnXK/FU2Ntj5dDMtyvzxj+w==@kvack.org X-Gm-Message-State: AOJu0YxVQ53pdggSiv2xKw/MWvcR23E8uLMWdOA5T7/+klsD8+rj1BZC Br2uNgAzOHceU7vXx6u1QuGs5abWIzJ1haheMrQx4d0IFvtOwnXLAREcNv88+wmJpsX+s5ut/vS de9j2FURt+BWFTazf5IXMr+Bx7ODM2v1rAnIt X-Gm-Gg: ASbGncuynZ87XQ5GPj8DEqtGHEVfAwbgFom8fBUM/uRKePTGJgZZS/gK/mazAVmmxgS 3uWDYtFXOwYQSU20VAN6Y9TQCANZ3BohLzylJLR/Rw0MdfzSny7477IkOWpChNct7XNKeJRx8z+ NX7C8Qqllt9YWyBn5/lKIo0Q== X-Google-Smtp-Source: AGHT+IEynk71rTo5QAU0nN+o2O+0yFjyQ113XZBjQvgh1uLkqf8zyYIq2nZaaxEVVWn37yekS9kI1R7YzDqNHi95Q40= X-Received: by 2002:a05:690c:7002:b0:6fd:6748:928a with SMTP id 00721157ae682-70559a6a25fmr75224277b3.29.1744409659266; Fri, 11 Apr 2025 15:14:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Moore Date: Fri, 11 Apr 2025 18:14:08 -0400 X-Gm-Features: ATxdqUHUqC_GnYV1ob9atu9iK3mHRkgbWg3uQONWT0Q0sNaX4f87ERAqln_Lkfg Message-ID: Subject: Re: Credentials not fully initialized before bprm_check LSM hook To: Roberto Sassu Cc: sergeh@kernel.org, Alexander Viro , Christian Brauner , Kees Cook , James Morris , "Serge E. Hallyn" , "Eric W. Biederman" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, linux-integrity@vger.kernel.org, zohar@linux.ibm.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6EAF5180004 X-Stat-Signature: sduqxfdgjof9kwc3ue1ybhcpbz4gbgm6 X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1744409660-815840 X-HE-Meta: U2FsdGVkX18Ykmu5UQ2x4yjhyePjLZQIZ29ehAtWmWQBBdtLIAQUFc7cR09iSb/HliFKWibz2XC7JofatBuGNUaXWZI6qRBuLNR7WW79N6siHv18jdKohap0jpDKJ4VUzMMYFrgRO5+ZixhrkjnTsAUeKZuWoDjzZFxRev0dQ6CHoluW7dgbyGaitXUM8u35Ll98DZ9T72/8YJC7JYDRicrvo023aan4AXNbT3KUREt48eCYSye71sBA74rlRP2xwOP/3+P4RKBR03Y+suaEI7ZRVIsp7WiWYAFPV1RqD6xQefivasF3cMPhrBdsVI+OQEZKuXdOyIgAo1VSyUXWeuR5ZaNGK/4wMvRnytxTRivbWNlWW3Dyur5199BNGidIYsXZMgXMZpOzqgShp7HfuZIPi7VuuyrEs6oR330daSGm5RhkYfTtDzdreVQ8NL5onU8h7fj2s60bpAhpvx6eLmnvCg7yD5zP7pKl2LBtYK6OIuxio2hxL7DemC2ARfVYDCwFTmM77sXYgyeH+ugvWIziX350hxgxQ3rC/NAP2h4QhtN+Wu5bW2dfVOUUEX2zic+Id6/5wZS9ZA/6fIbcQx0zJzxTqtKyHXNO+GgAEJj3BdzmS+lxoa7uO7kwduhDOnVvsxnC8sp8x+Uq0Ihwfx9ftSAXnoynyUVUbd/KgFapz+l297bgnCOocblZ7WXbSk5R8U0VErlfR/BorLY6EbViBdTwaL4lX8xyIcMHlRKb1RISrmYYRqVyB8mnxfRAjLUpaJ2ExQ630fNY3jX1CbDhQnjVJLP5Pg/xPDp8PVhS95sxQz/JnjAnL5LpD+TQ1HaCjbZjCK5Gd2vfB0jDqNMPpQO4zhWbM/mHAK89v03MB8JGixShkaaOxw0MFxGFrMQTqu+zh0vnDtSmdJzhpzkS+Q8jNt/UnBeTSEDUEIYVzQYWr3a4IanLAH7rNhXzifzx1mfJPTsoc+51Y2k 8ddEHxFh 4IYRV46FOXcdV7cEkeC86EciuRO8fuQufiaxrKi87g9YIk+TSc68RfppeEbZISnFHNXMKChhFzxDupOCpKQBL4ovs3HcnqP77tF5+q9QCbwtJC71wWnJNhBINlikw11X0aZndv/k3Y+Og12eu/G5JHr3p4uKRLBwkvMNTjPGAJ2dcaZToloPYIKe3UQtjXzWg3HJTgZ4pChjyxTe5E/fLzayGZVmvU46zwVwQtnyPpn08UbTIKHmyT+3jplvpQebBzOETBMO4mGe6o1FK78VaS+mXzpqmgrMbJKNNxqwXrDRLos+GhE8IrZpNgEBVtvSHiqFBBEudEAlmP5gLzwiBUr4H92cuZ5A3zTuK6o2DyauOa7A= X-Bogosity: Ham, tests=bogofilter, spamicity=0.101821, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Apr 11, 2025 at 5:07=E2=80=AFAM Roberto Sassu wrote: > On Thu, 2025-04-10 at 17:24 +0000, sergeh@kernel.org wrote: > > On Thu, Apr 10, 2025 at 01:47:07PM +0200, Roberto Sassu wrote: > > > Hi everyone > > > > > > recently I discovered a problem in the implementation of our IMA > > > bprm_check hook, in particular when the policy is matched against the > > > bprm credentials (to be committed later during execve(). > > > > > > Before commit 56305aa9b6fab ("exec: Compute file based creds only > > > once"), bprm_fill_uid() was called in prepare_binprm() and filled the > > > euid/egid before calling security_bprm_check(), which in turns calls > > > IMA. > > > > > > After that commit, bprm_fill_uid() was moved to begin_new_exec(), whi= ch > > > is when the last interpreter is found. > > > > > > The consequence is that IMA still sees the not yet ready credentials > > > and an IMA rule like: > > > > > > measure func=3DCREDS_CHECK euid=3D0 > > > > "IMA still sees" at which point exactly? > > IMA sees the credentials in bprm->cred prepared with > prepare_bprm_creds(), where the euid/egid are taken from the current > process. > > > Do I understand right that the problem is that ima's version of > > security_bprm_creds_for_exec() needs to run after > > bprm_creds_from_file()? > > IMA's version of security_bprm_check(). security_bprm_creds_for_exec() > is for checking scripts executed by the interpreters with execveat() > and the AT_EXECVE_CHECK flag. > > Uhm, it would not be technically a problem to move the IMA hook later, > but it would miss the intermediate binary search steps, which are > visible with security_bprm_check(). I'm still trying to make sure I understand everything here, so I've got a few questions: * How important is it for IMA to vet the intermediate binaries? Those binaries don't actually do anything with the program/scripts, right? * Based on the comment block at the top of begin_new_exec(), I'm assuming that using the security_bprm_creds_from_file() hook would be a problem due to challenges in returning an error code? There might also be an issue for any LSMs that run *before* capabilities, but I think that would only be Lockdown in the default case so likely not a big problem. * This patch has been out for almost five years and presumably offers a performance bump when doing an exec; I'm skeptical that Eric, Linus, or anyone outside of security/ would be interested in doing a revert to better support the AT_EXECVE_CHECK for a LSM. Yes, I might be wrong, but for a moment let's assume a revert is not an option, what would you propose to solve this? If you can't think of a general solution, can you think of an IMA specific solution? --=20 paul-moore.com