From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1BBA8155C8E for ; Tue, 9 Jul 2024 10:06:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720519590; cv=none; b=eCVxGAb8PyhyS5GJfkofBTUq1e/IqN6Qy5sEOnRed5YsxaAWMlqmf2yeh0g5InT6cRtESd9C1GNphipSjLa1ogsyLUf4XkrhWh6wwQ3LIuW7CaKOGJAnDP9TTWM128dEhKmGD1X5EMuiOAFxKSgsUoUOqA5cSB14Ys7z7GtupFo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1720519590; c=relaxed/simple; bh=/KRfE1rWf1wyqso3Vkt58rj1kXw2cVDyjzWknY+bgYk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=LSlo+GXQco6o6hfaWTBXcCPIFiLD0OjtsrsLUNTipjV2izzIFo+LKEwVWXt5zuaYS7n2JT7Qug7nfTbJJOtM3JVrFtckf2v/y8mZSejA2aAvOzzhODuywrs1BFXoj00Ttpk2YJjh3vJrTDaIDwE5GxsqgCpN/LbOBtgx7EvPlTE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Jmxx1qkT; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Jmxx1qkT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1720519588; h=from:from: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; bh=tjTUnc7IhcTY8yXbQZCHDpYRmcDVvOi7wtfkPwMCZy4=; b=Jmxx1qkTxK7lv9nfnILaf/LRMAbZ0ZrxJsn9+rR2fGMZ3N0JczgUYyEgq6X4gqeiXBm3SP 91Nb3Ubn7bF44Uc96BfLUZCE/1eKPCbEtPCvp2tNpx1JvyV+tlm+a8PG1EjzNF/GBQG9fE RRSVW0Pm/eGfzhoKPvOkd5n749e0TNQ= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-361-UiV9XaiFPlaMJoCqgi_zcA-1; Tue, 09 Jul 2024 06:06:20 -0400 X-MC-Unique: UiV9XaiFPlaMJoCqgi_zcA-1 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 4F23819560A1; Tue, 9 Jul 2024 10:06:12 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.224.64]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id ED1F13000181; Tue, 9 Jul 2024 10:05:53 +0000 (UTC) From: Florian Weimer To: =?utf-8?Q?Micka=C3=ABl_Sala=C3=BCn?= Cc: Jeff Xu , 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 , 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 Dower , 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 Subject: Re: [RFC PATCH v19 1/5] exec: Add a new AT_CHECK flag to execveat(2) In-Reply-To: <20240709.gae4cu4Aiv6s@digikod.net> (=?utf-8?Q?=22Micka=C3=AB?= =?utf-8?Q?l_Sala=C3=BCn=22's?= message of "Tue, 9 Jul 2024 11:18:00 +0200") References: <20240704190137.696169-1-mic@digikod.net> <20240704190137.696169-2-mic@digikod.net> <87bk3bvhr1.fsf@oldenburg.str.redhat.com> <87ed83etpk.fsf@oldenburg.str.redhat.com> <87r0c3dc1c.fsf@oldenburg.str.redhat.com> <20240709.gae4cu4Aiv6s@digikod.net> Date: Tue, 09 Jul 2024 12:05:50 +0200 Message-ID: <87ed82283l.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 * Micka=C3=ABl Sala=C3=BCn: >> > If we want to avoid that, we could have an agreed-upon error code which >> > the LSM can signal that it'll never fail AT_CHECK checks, so we only >> > have to perform the extra system call once. > > I'm not sure to follow. Either we check executable code or we don't, > but it doesn't make sense to only check some parts (except for migration > of user space code in a system, which is one purpose of the securebits > added with the next patch). > > The idea with AT_CHECK is to unconditionnaly check executable right the > same way it is checked when a file is executed. User space can decide > to check that or not according to its policy (i.e. securebits). I meant it purely as a performance optimization, to skip future system calls if we know they won't provide any useful information for this process. In the grand scheme of things, the extra system call probably does not matter because we already have to do costly things like mmap. Thanks, Florian