From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) (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 8810C14F117 for ; Mon, 8 Jul 2024 22:08:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720476485; cv=none; b=GH0j9xR0BPLLP6crKq9BbSPohEz7tyGHM9OwtF75lyJ36ALrZ/chm1yta21EXiSf+rUg8hfMC8EtyFBxHrBS7aWgc02wFIrnbPyjQ+wLryZ3ct33wxEnqJIvx26kPcn7jsLqZVBd3FDfo924qC88+HPIGQjsew5k0ulx9t0LDoA= 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.54 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-f54.google.com with SMTP id 4fb4d7f45d1cf-58ce966a1d3so2785a12.1 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=iJdZjXvqNPmWzAlMTMd4OUbnb3elmg2t676upS6lv8lSXLEQ8/RBS+MALNvplaRvcu 8Npb6xiNb5r9YEW7MNq4vsc1fuSmyjjdBYqLJ1RAuwl5j+3p9C69VX7k6CMiaotd9/eT W06p2aWi1+6bYRnQjrdsRFXASqefW7NOxxf0yaZtv8Hgmk7PvLf++vgni0iPyt5L3QN0 N3q3i+pbYKMcJMPuqEFsYNJvjV62/D89VUjpCT5iapEVCIkyIP4eraVJUqOCiR4K0lCe ou3hS0xSEzWSUGVPllLAm73Pi3y+ngcqBBq2oomVXa/07FYbnItumGoSHQ8nTxnU/bRn PWTA== X-Forwarded-Encrypted: i=1; AJvYcCUOg/8d2Qfi4j79ThJ2shvUSq1cgNyDJEg/P8ye4lFO7Qj1m00fIh7NS5xLAZYbNVZPANejHv+rzJlAmboYh2iD0vyZpkAHKEAhzsOmj4FXGHm5okIn X-Gm-Message-State: AOJu0YxYpq2YmB+ahXOrhlmSZDDCjC2PS0YuAqsDz/JPxaNHKH8O+1gL JSF6llgwdBbP0g8fLO0wbuqpqdUw/UB58GqxZiVy48WpwAJbq21OGkLBKNLj6p5tD/sfKNYesFD sShwsAcNvt9gDkWp0VaCgdXuJUEuM4GscW/It 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-security-module@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