From patchwork Mon Dec 26 19:30:54 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Peter_M=C3=BCller?= X-Patchwork-Id: 6335 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4NgnvX00tBz3wcv for ; Mon, 26 Dec 2022 19:31:03 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4NgnvW1QyZzwp; Mon, 26 Dec 2022 19:31:03 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4NgnvW1N1dz2y0s; Mon, 26 Dec 2022 19:31:03 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4NgnvT5KWyz2xmd for ; Mon, 26 Dec 2022 19:31:01 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4NgnvR2kwvzHs for ; Mon, 26 Dec 2022 19:30:58 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1672083061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=am2jLKoB2vfEKBlEbj+0cZjM7+sdz5/TxQ/kDxUb7lA=; b=8N40SYrbUv3KbB2xrQ8+o/3lsue2z6j9YWX7CywZhM3ZVESdb3SYcu8kusNKTePS783Rtp 7AzTRyqtp6vxgZDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1672083061; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=am2jLKoB2vfEKBlEbj+0cZjM7+sdz5/TxQ/kDxUb7lA=; b=XWj6mQtBziN8noS9KJcc3nYiUeq/rZ73GCuYXxZmFNnUox7mZXUxWdvg88Td4k3Ae8kqR4 xLt/a+FSvcxqKv/QPMAKfOr0DOZBBllE2/cHY7hoijvPfJATWRCmP48JHff3su0rxqmybD MS0uRsROPyRkCKW0deFSD5f4iJPMbeWk52YA3nZl77fGLfBMcEG/+rEKXJYKhN3+GMmlhs wRVGDEdCifPQh4qENl6lNyRVoQuOYp+AdxYvrPpm499vhjPOQwOFrNtNTWuXRfHC+jE9hE SXLqGuUO2nNJlSFrYVO17kO2I3GhJCQXkNdarkpzjeDegUCsDtOmQPHVySr7BA== Message-ID: <6f89772f-8082-e4bd-d2eb-8c0a16f00a42@ipfire.org> Date: Mon, 26 Dec 2022 19:30:54 +0000 MIME-Version: 1.0 Subject: [PATCH 19/21] linux: Enable Landlock support Content-Language: en-US To: development@lists.ipfire.org References: <0e60a1de-6210-835e-54a4-ec5e3128e42e@ipfire.org> From: =?utf-8?q?Peter_M=C3=BCller?= In-Reply-To: <0e60a1de-6210-835e-54a4-ec5e3128e42e@ipfire.org> X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: development-bounces@lists.ipfire.org Sender: "Development" From the kernel's documentation: > Landlock is a sandboxing mechanism that enables processes to restrict > themselves (and their future children) by gradually enforcing > tailored access control policies. A Landlock security policy is a > set of access rights (e.g. open a file in read-only, make a > directory, etc.) tied to a file hierarchy. Such policy can be > configured and enforced by any processes for themselves using the > dedicated system calls: landlock_create_ruleset(), > landlock_add_rule(), and landlock_restrict_self(). There is no harm in enabling this security feature, so applications supporting Landlock can benefit from it. Rolled forward from https://patchwork.ipfire.org/project/ipfire/patch/d7ac0caf-5a7c-bcca-6293-16c773523942@ipfire.org/ to submit all kernel-related changes as a single patchset. Reviewed-by: Michael Tremer Signed-off-by: Peter Müller Acked-by: Michael Tremer --- config/kernel/kernel.config.x86_64-ipfire | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config/kernel/kernel.config.x86_64-ipfire b/config/kernel/kernel.config.x86_64-ipfire index 3d9e01e38..3bdbf3476 100644 --- a/config/kernel/kernel.config.x86_64-ipfire +++ b/config/kernel/kernel.config.x86_64-ipfire @@ -6874,7 +6874,7 @@ CONFIG_SECURITY_DMESG_RESTRICT=y CONFIG_SECURITY=y CONFIG_SECURITYFS=y # CONFIG_SECURITY_NETWORK is not set -# CONFIG_SECURITY_PATH is not set +CONFIG_SECURITY_PATH=y # CONFIG_INTEL_TXT is not set CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y CONFIG_HARDENED_USERCOPY=y @@ -6893,7 +6893,7 @@ CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y # CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set # CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY is not set -# CONFIG_SECURITY_LANDLOCK is not set +CONFIG_SECURITY_LANDLOCK=y CONFIG_INTEGRITY=y # CONFIG_INTEGRITY_SIGNATURE is not set # CONFIG_IMA is not set