From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f50.google.com (mail-yx1-f50.google.com [74.125.224.50]) (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 CB6FA3515D8 for ; Mon, 3 Aug 2026 22:31:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796281; cv=none; b=jhYZXoZA5jWhBr3s2nlEjVYmovKqee/qkZe4nLkReDgQlIpIJXWhqr5d2yrpK9FtsYEDECXpEJZrlcWdHLAzF7Wz8cuGQ2J8n3cy9dbQxJA+J4LYazz7TcAlNFBElY5zuxyX033Nv7IKQ8isp9bR1X0wsZVndKgOEkaBgPO08aM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785796281; c=relaxed/simple; bh=KhNmQPKvwOQ+mniwSSLAoC9sjghgdGDHBXnf9xXMVX8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qKGXtkpHuuOA1SmjYai+X8VRzJSEVDlCwNPVCfzYOz9NoC+Bmh9UxvQ2tKfh2WLvAZUk1pVYLLpi9FQUn3B8uM3imgku22T5tB6NhOlp/xmE2BeWGq0dkj9970crktZoi1VWQT84CI75HpppbZ6Ikz2Z58vr5LxMIA7REBGrdUw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PB3oDy0Q; arc=none smtp.client-ip=74.125.224.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PB3oDy0Q" Received: by mail-yx1-f50.google.com with SMTP id 956f58d0204a3-667971437d6so5437368d50.2 for ; Mon, 03 Aug 2026 15:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785796279; x=1786401079; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=e5s0xFKMZYCXt2wJGBakETq4pnBg/XsA2VPADzOv0sc=; b=PB3oDy0QD988WiidHp9mL8hfvIqXe0bNmwrEGjcX9LjZcnypQzM2wSiBT/XxSBC8OK 2fAEnRAsjS9ddBFIf2MvuixQ9dNZ4iMF+WBCSGkktSIwuzupLy4ohH/CN3lfA3RwK+Cn u3Ofmoaonix7+RZkvEHFG/YU02C6LBBDXQqKp5TuCEBG4cpU/lKfHXg9kQ9rQhxeW/PB DRf4BLyTY803Hlcr5Veu6rc9eqOibMLIGHl8/UdwhXdkY0GrABPoqyuDrBIO+0zFLWoD z53Wy4n/uBQxGNbBECVmK2zeizenPOhKWdPZ8oO6C2mYnUDUGugQDT6pTU8+1vxhpQSj s5PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785796279; x=1786401079; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=e5s0xFKMZYCXt2wJGBakETq4pnBg/XsA2VPADzOv0sc=; b=UUfKrmfh0e8w5PHwL7/TXxfT51xpUV85bzAR3zmR2PQUHzBWyvf/8gzxVlbqpxhuSq mgFhgiJuduz7VxEjyMaCZ6ENbaxEgXik+bVAOWILIZi1SYSyf83ujsrkci345VoCvzKp Y9gkX3pjocbdF0WiKLXirm7vkufNmFB8zvOam2MgxKLyz7KX04FgbdDzlR4E0C5J/RAZ Mpl2s8essdtgypSESYUSdcBxB98q1Zb9NHBMQxQq1DL0/iEKp5ls2fizGOKYyollRolp OwWqK/BP1rN2w2sS9JZZ//7il2x7+oS7WcmaxD8hTLSlxADmnss4LiP/1MUg+2C/HYKW 36TA== X-Gm-Message-State: AOJu0Yx4U+xE11iJmGxuWPa34AmQYZuOvQRRQuz3CocPPRc2V4cO+JfX e+SJ2Sf11m02USq7vWmzagtH8HqG/oKd89GbfCTP5bVYprsIad8NPem3 X-Gm-Gg: AR+sD13Zy12NFBMBNR2zWkTilfBjbnhLRRXRKgvkQ3TKJ/f0TLBCC7E5vtSxxdo/moa sgnFZ71IglwvY6wrPFcK5nS89OKyFx5XhqhzlxZXDTf09QgMN/liMHy4DEkFdGjz1LtmsiHDPnV 1iTNkywe7qhPiVeSTT4RRNBkf/qUqjEbHm17xc1CJp9TAkrtKqSiplejW+WhYRSdymgQc6JVUDj lEcUhkYWwPFPrsMy6DCUuGdcAtVgBoySVy9dXDkRAOuslpB0xcdP1InW30LTCyNMj3Q/V7bmtWp i65Da8IA03EWhuj3+OSHYOT3EtQ2KHbHInFROdOzjjnYSWgQ1nLznB7eKqRxBLhBkcaqD36RG7u PdSoXAV3kqtE+2n6BkmXbqNxoYqghpKIfDSBKnNuYT9i9aN39k2ciyOLjLlzhic2IDfg/SlEQIF x3A1XFPw3ywHvJrzibbViuMBfCXHHo/vp2k6grGu3Mx+pABdQwd/kv2Isi4HrC/APsqjPze4vqg JsrxUGNKY3sh1T20yfVRtM= X-Received: by 2002:a53:b4c9:0:b0:669:483e:c36a with SMTP id 956f58d0204a3-6694f17092amr10482172d50.34.1785796278794; Mon, 03 Aug 2026 15:31:18 -0700 (PDT) Received: from zenbox ([2600:1700:18fb:6011:6253:b407:801c:a745]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6694903782fsm6420774d50.21.2026.08.03.15.31.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 15:31:18 -0700 (PDT) From: Justin Suess To: gnoack3000@gmail.com, mic@digikod.net Cc: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org, Justin Suess Subject: [PATCH v3 3/4] landlock: Document LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS Date: Mon, 3 Aug 2026 18:31:07 -0400 Message-ID: <20260803223109.707353-4-utilityemal77@gmail.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260803223109.707353-1-utilityemal77@gmail.com> References: <20260803223109.707353-1-utilityemal77@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document setting no_new_privs with ruleset enforcement, following the same compatibility section style as previous ABI additions. Include a section explaining the tradeoffs of setting no_new_privs through any means for privileged users of Landlock. Signed-off-by: Justin Suess --- Notes: v2->v3: - Update the tutorial: restrict_flags per ABI version and prctl call skipped when LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS is used - Drop "Atomic" from the section title; describe the ordering instead - Explain that not setting no_new_privs is risky even when not required - Fix ABI 8/9 switch coverage (case 8 ... 10) and indentation Documentation/userspace-api/landlock.rst | 47 +++++++++++++++++++++--- 1 file changed, 41 insertions(+), 6 deletions(-) diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 5085822d8930..0e4a73fd5ea4 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -8,7 +8,7 @@ Landlock: unprivileged access control ===================================== :Author: Mickaël Salaün -:Date: July 2026 +:Date: August 2026 The goal of Landlock is to enable restriction of ambient rights (e.g. global filesystem or network access) for a set of processes. Because Landlock @@ -250,7 +250,8 @@ similar backwards compatibility check is needed for the restrict flags __u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON | - LANDLOCK_RESTRICT_SELF_TSYNC; + LANDLOCK_RESTRICT_SELF_TSYNC | + LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS; switch (abi) { case 1 ... 6: /* Removes logging flags for ABI < 7 */ @@ -269,16 +270,36 @@ similar backwards compatibility check is needed for the restrict flags * children (and not for all threads, including parents and siblings). */ restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC; + __attribute__((fallthrough)); + case 8 ... 10: + /* Removes no new privs flag for ABI < 11 */ + restrict_flags &= ~LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS; } The next step is to restrict the current thread from gaining more privileges -(e.g. through a SUID binary). We now have a ruleset with the first rule -allowing read and execute access to ``/usr`` while denying all other handled -accesses for the filesystem, and two more rules allowing DNS queries. +(e.g. through a SUID binary). For unprivileged processes, setting the +no_new_privs attribute is required by Landlock. + +Processes with ``CAP_SYS_ADMIN`` in their namespace can enforce a ruleset +without it, but not setting no_new_privs is risky even when it is not +required: sandboxed processes could still execute set-user-ID, set-group-ID +or file-capability binaries, which would then run with elevated privileges +while being restricted by a Landlock domain they may not expect, making them +potential confused deputies. Setting no_new_privs should only be avoided if +such a privilege transition is expected. + +We now have a ruleset with the first rule allowing read and execute access to +``/usr`` while denying all other handled accesses for the filesystem, and two +more rules allowing DNS queries. .. code-block:: c - if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { + /* + * If the ABI > 10, we can tie setting no_new_privs with successful ruleset + * enforcement and skip the manual prctl(PR_SET_NO_NEW_PRIVS, ...) call. + */ + if (!(restrict_flags & LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS) && + prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)) { perror("Failed to restrict privileges"); close(ruleset_fd); return 1; @@ -792,6 +813,20 @@ when at least one sys_landlock_add_rule() call is made for it with the ``LANDLOCK_ADD_RULE_QUIET`` flag, additional add-rule calls for the same object without this flag do not clear it. +no_new_privs flag (ABI < 11) +---------------------------- + +Starting with the Landlock ABI version 11, sys_landlock_restrict_self() +accepts the ``LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS`` flag, which sets the +no_new_privs attribute of the calling thread only once the enforcement of +the ruleset succeeded: no_new_privs is set if and only if the call +succeeds. This removes the need for a prior :manpage:`prctl(2)` +``PR_SET_NO_NEW_PRIVS`` call, and with it the ``CAP_SYS_ADMIN`` +requirement. When combined with ``LANDLOCK_RESTRICT_SELF_TSYNC``, +no_new_privs is set on all threads of the process. As explained in the +tutorial above, not setting no_new_privs is risky even when it is not +required. + .. _kernel_support: Kernel support -- 2.54.0