From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8990214F13A for ; Mon, 8 Jul 2024 22:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720476485; cv=none; b=Bkz9rhLICWmfr8g2ddRRmFmMWvGoMVdvJUtr/mHCPsiLnHHgUXI3JBJZG90y2aACINgUY2carVot85E5TJ3mrRff9NPPXzIURQfOfw8b8Wl8nOOMt3kwOqIZ456T9HAQ+bzvM3KqrEfLPPhIzw3WlpJ5CASJLi0Ai8+gyjY1OfE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720476485; c=relaxed/simple; bh=l03sVvdiatScP8Ji7LS+51efo1XSZO8mK8zgUFzmJb0=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PVVY75mdUTrjEpw+8u9AvQz+GkNxhMZbTDE2CUtm4DQAK+TCD6p5VbxAoCaOlml2cboc4qD3hozR9u05CFGhhBRVKLnJVOIM5q4IuftiDtX1Wqcz0kzSCuH+/GJOFCDoFOcd4MGb1+CBiwci8BzIcUoSlpGHKXINUN+Z6ZvDvEI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=c6txaJqS; arc=none smtp.client-ip=209.85.208.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="c6txaJqS" Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-57a16f4b8bfso5507a12.0 for ; Mon, 08 Jul 2024 15:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1720476482; x=1721081282; darn=vger.kernel.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=Z7bTn4O9eTr2aCFrLSGHovaOIDt2y0TRFcSEpZcps+A=; b=c6txaJqS6Ki2CUPrvyQzKfnl8agf/jflzpSrhBegMCgJMdzWyE1yPGl3EHeUnjRqS7 FZr0smtAZkCeRoGHgRD8zKTFVpxlbw2DDkrZ9FZE4KLkobwe6E8L4CReaAT2jeid8VOq R5+U+p/a3RvQxjOwd/XAte1z9TrMsmVWV3Mtqf2+KssLNK/Px1qL3+4aVyEBhsi7xlK+ jcY3AqzrUE3bak3fj25i6lrQbtSDnzaRHqx6dIkzvPYqI6qZwQsjnaAP2+e4PJTeWSCK c/JKePu8wg4B2VJn6c4DrJTSM7FbdWLPNQYErl5x6m2cpqmJdaiX44c7d0oug5cU0V6w agZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720476482; x=1721081282; 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=Z7bTn4O9eTr2aCFrLSGHovaOIDt2y0TRFcSEpZcps+A=; b=BXT1iFds4H3bspWIiOUEiunfLopT/GwRtRPO9qnFt3m09HVVNLVybF6+I2Zs6d7HF1 G1k+MOeX069Zuj9m7WCZUL2bE2Zz4LxZSDGvZOAejLPIBycl3wA8QMPGH0MWco6T2u+x 9bDeOhJkrQv2K9bbT0Ymq4M4Hf0IsLBjf+8CTlwAYtav1xRrjPh+YhmhFKNoFed/kugP Ckil43QWzqw/J2H7mzGE260JvT0XX/jxpcOlR2dsCjV1sYIZtIh/Kuhb8/jxyrkbjbGh GFJ9ZAzo3lYyoT6hl0+tsHhnTBemyJHogC9ZEwJi0GXS6kkfxYD8wRkPO6OzbdA8gPy2 L+Bw== X-Forwarded-Encrypted: i=1; AJvYcCUdsTjMnLQUpUTCg3dUIVFWUEZWjOqS0brci7EhMjDFcun5OXMXfW0wowntq32RE3zBAwmnukuvEn2wnzsfueRFlR4dsqnmm1LyMFVOKA== X-Gm-Message-State: AOJu0YzGlIrqx5f2QWLhcHVhkkRuNbvYudmHqfK3aTuyq20OA3eGAQQh MNWJngKeiyEYaQL53b2taIyohuPZMyK+7wYiq+awYGIOJ2rMNaqkopLhm7MRIJkMhoQ2Gv1B3mG 0fng6B/jnktvHZk9A4g7t8MnRqYESlE7oj0wN X-Google-Smtp-Source: AGHT+IHvwrZF+sD8hiUMuOI0mETWWoP7JD1Mi+rw83YkQOqjyP7kYFiISHKE1V9Tv7EGbEO+Y6qMxWIETtxF0JNU+kY= X-Received: by 2002:a50:9fc1:0:b0:58b:21f2:74e6 with SMTP id 4fb4d7f45d1cf-594cf64511dmr86189a12.0.1720476481691; Mon, 08 Jul 2024 15:08:01 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-3-mic@digikod.net> <20240708.quoe8aeSaeRi@digikod.net> In-Reply-To: From: Jeff Xu Date: Mon, 8 Jul 2024 15:07:24 -0700 Message-ID: Subject: Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits To: Steve Dower Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , Al Viro , Christian Brauner , Kees Cook , Linus Torvalds , Paul Moore , "Theodore Ts'o" , Alejandro Colomar , Aleksa Sarai , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Christian Heimes , Dmitry Vyukov , Eric Biggers , Eric Chiang , Fan Wu , Florian Weimer , Geert Uytterhoeven , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Jordan R Abrahams , Lakshmi Ramasubramanian , Luca Boccassi , Luis Chamberlain , "Madhavan T . Venkataraman" , Matt Bobrowski , Matthew Garrett , Matthew Wilcox , Miklos Szeredi , Mimi Zohar , Nicolas Bouchinet , Scott Shell , Shuah Khan , Stephen Rothwell , Steve Grubb , Thibaut Sautereau , Vincent Strubel , Xiaoming Ni , Yin Fengwei , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 8, 2024 at 2:25=E2=80=AFPM Steve Dower = wrote: > > On 08/07/2024 22:15, Jeff Xu wrote: > > IIUC: > > CHECK=3D0, RESTRICT=3D0: do nothing, current behavior > > CHECK=3D1, RESTRICT=3D0: permissive mode - ignore AT_CHECK results. > > CHECK=3D0, RESTRICT=3D1: call AT_CHECK, deny if AT_CHECK failed, no exc= eption. > > CHECK=3D1, RESTRICT=3D1: call AT_CHECK, deny if AT_CHECK failed, except > > those in the "checked-and-allowed" list. > > I had much the same question for Micka=C3=ABl while working on this. > > Essentially, "CHECK=3D0, RESTRICT=3D1" means to restrict without checking= . > In the context of a script or macro interpreter, this just means it will > never interpret any scripts. Non-binary code execution is fully disabled > in any part of the process that respects these bits. > I see, so Micka=C3=ABl does mean this will block all scripts. I guess, in the context of dynamic linker, this means: no more .so loading, even "dlopen" is called by an app ? But this will make the execve() fail. > "CHECK=3D1, RESTRICT=3D1" means to restrict unless AT_CHECK passes. This > case is the allow list (or whatever mechanism is being used to determine > the result of an AT_CHECK check). The actual mechanism isn't the > business of the script interpreter at all, it just has to refuse to > execute anything that doesn't pass the check. So a generic interpreter > can implement a generic mechanism and leave the specifics to whoever > configures the machine. > In the context of dynamic linker. this means: if .so passed the AT_CHECK, ldopen() can still load it. If .so fails the AT_CHECK, ldopen() will fail too. Thanks -Jeff > The other two case are more obvious. "CHECK=3D0, RESTRICT=3D0" is the > zero-overhead case, while "CHECK=3D1, RESTRICT=3D0" might log, warn, or > otherwise audit the result of the check, but it won't restrict execution. > > Cheers, > Steve