From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.python.org (mail.python.org [188.166.95.178]) (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 C6B561EB44; Mon, 8 Jul 2024 21:32:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=188.166.95.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720474364; cv=none; b=n7eSAGpPCxiD/50PmjMj7/X+g1nkxGyh/vCqkOF287ZlSJndoL90By7p1AB7K7MTtIUwuF/y9FVsR6LqopxLGdEMIRA2H9xhT/WoBAz+Z376KdkuYO5NGxzQexgEoqaDexKadrocbdIQFYSm/ifeNxXj3D0dJmgCHXrLYQBDHz8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720474364; c=relaxed/simple; bh=qP9JJjp2wwtgqNEqstI/ReNHBLe0F8Tj7JsMZZjC+tY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=keNbQ3Ecg/lne3KvXI14s7Qfm3wQKR4SxkCatKDKcvsiekKX3OkHizkX9dBRcwlgn/mGxhQLXJCS9SSn36X5ZwIH+eeU1sqAiZ12zSLko/cwtUJwb2xc88CX/JecFeFv2tlZdiaiaRrsnY22zKewSmF+2ZW0OmZPztmOgzrTIDA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=python.org; spf=pass smtp.mailfrom=python.org; dkim=pass (1024-bit key) header.d=python.org header.i=@python.org header.b=fRvlg0QX; arc=none smtp.client-ip=188.166.95.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=python.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=python.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=python.org header.i=@python.org header.b="fRvlg0QX" Received: from [192.168.1.83] (unknown [2.29.184.121]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.python.org (Postfix) with ESMTPSA id 4WHxxK6lcqznVF4; Mon, 08 Jul 2024 17:25:41 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901; t=1720473943; bh=qP9JJjp2wwtgqNEqstI/ReNHBLe0F8Tj7JsMZZjC+tY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fRvlg0QXwIJAkXyrCKhMDJxtPyAXB0mjii1640HG3xWRb2W5P+42eQTBJPTIuhKpt W7kH1zP794uZGf0rnntp5p+gP5s1k2YsFyKXYqxePPc8Ng44leBwaQk7RKeO5U7X6v HzB8cs5L4tQul4iZaKKGJIvbQF7weKnmuCGRaspc= Message-ID: Date: Mon, 8 Jul 2024 22:25:41 +0100 Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v19 2/5] security: Add new SHOULD_EXEC_CHECK and SHOULD_EXEC_RESTRICT securebits Content-Language: en-GB To: Jeff Xu , =?UTF-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: 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 References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-3-mic@digikod.net> <20240708.quoe8aeSaeRi@digikod.net> From: Steve Dower In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08/07/2024 22:15, Jeff Xu wrote: > IIUC: > CHECK=0, RESTRICT=0: do nothing, current behavior > CHECK=1, RESTRICT=0: permissive mode - ignore AT_CHECK results. > CHECK=0, RESTRICT=1: call AT_CHECK, deny if AT_CHECK failed, no exception. > CHECK=1, RESTRICT=1: call AT_CHECK, deny if AT_CHECK failed, except > those in the "checked-and-allowed" list. I had much the same question for Mickaël while working on this. Essentially, "CHECK=0, RESTRICT=1" 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. "CHECK=1, RESTRICT=1" 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. The other two case are more obvious. "CHECK=0, RESTRICT=0" is the zero-overhead case, while "CHECK=1, RESTRICT=0" might log, warn, or otherwise audit the result of the check, but it won't restrict execution. Cheers, Steve