From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 3DD0431A55B for ; Sun, 30 Aug 2026 20:17:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788121035; cv=none; b=LmCwAlaK6hF+avd4XvENEMdEttHfngZvVn4xLcIzwZQQ9YtlwOQsPi6LAHs2QWKH23BWjCxoxstwEO/9cdk1+ayDJmtvGd7L8zhV3wwbsEqrJbCgvU9+w+ywtWn1qFcymEax6xEfcb9JiXHhrEIy2VDik3TDR2mLZuaVdZ4FkPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788121035; c=relaxed/simple; bh=qnBuxHRm0ZKAQlNWrNsQLPpAatqA7MRJqtCeBnPdJco=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jI0GNmxRkz8W8yQ5VVGds3XAl5JhsAFrQ1wZ1hk50UqD7vMVs91x4Q3fMjWKkhE5NGZN6sXLnDmojaMCXMPUhTu63RgoeUnPqdK0ZW1GUHUPQhUhEWU2fP2WqS3BOzg0Y+mU/6h6aq8Iz/8MidkUXpGn+ir62U9e0kK2PBNmr7c= 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=WiPjRTwg; arc=none smtp.client-ip=209.85.128.49 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="WiPjRTwg" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49b96837ca3so15013135e9.3 for ; Sun, 30 Aug 2026 13:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1788121031; x=1788725831; 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=WuLxHG99e7u2lGKea2+n10AjWQDCxmpN+ylQ+0r2DPw=; b=WiPjRTwgZHZz5gqY9fpb7d4A7JN/czmHcPHnZVgwR2kFcIzPxmrIiUrBqiGuMjbW+t dd4VAt2A+KMGsOlqs1wgWPc/WBjcX/bjpTop7H4PjThj3l7St8EJGore4jGYfVHh6ru5 07aQy4svkk/p0wvX+pnq1hopk30ZMQtYEhU5673HKx9YlOas0jVKcngtGSx8Km2zVfkq ZPaJVy3ySPNwJ+kWynSy0oEOmD4cHGreHRLkftQJh+Q7ko0OgmJkqW0NZAqbTRkpbiUG c9g1ZLBl3gNMqcpiBcYYN95EnHOSZl0/iYMxvane6XbefOUASvD+bWTrz3QeFgh0J0r1 iMqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1788121031; x=1788725831; 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=WuLxHG99e7u2lGKea2+n10AjWQDCxmpN+ylQ+0r2DPw=; b=WlaIVw9TqQ5N5gkZ8mJHEapzo25e16ppYPLCi9+HLdFSfa6DFz2Y89Fyi1BS/PnoPg 2jnVom8z8qnOCQmB0UE+3kkCTV6nOKkhB/CD+eH5lNi6Fy+ssVv2JqTAS+vyIblA6lYf AqxuFvS/D7gDEiHG77IOnqrd5xzWZfpUxECZTcVjFoDbo4RbmSW/ZRG6xPagc+LKDgGC xvpheXIcrNwwrEUDA/0SEiEioH/XUJAiGUnLXsifW7+DFIG6Mv2GHDQJ01T19SI6N6WE SQ2yck221h/JMwHy9BdxHpdp+LsKeS3dbTT3JAIROzvKxvdybdEiPZ5icYbhc9XBgQ6H Ykvg== X-Forwarded-Encrypted: i=1; AHgh+RoX8rOM0ahHScFniQadN/XLieRAGbKRsFyJS9Y7TTqJ+xUl5D+DhFCMtKkV/xi7lEiQcDIv+Lg=@vger.kernel.org X-Gm-Message-State: AFuF++lMs0NwAnAVxQDiVZd5nsQgryslSQlsJorzVyzqPDv2GKHhD/by 4tcfBsILFhWIWvZSbC8vkkFHOcb0yOjItoaoCEtGwkCb82+NytucXA8ucr86fJtC X-Gm-Gg: AR+sD12CnpDJqj1YgLqylMdCLlrUwFXAV98ZKJatLsWR0uVaELVIn7vu2SEjgYTYwFf +GE/K92768cR8OUji/UbXL20ISSRu9H+Z/UPaRUvVtjB7KAjvCSGtPeJFSap+Y2S0mQjGydL/Ws FSTkabLHGLL6+tIc5o1P7E6xqArJgegSsWtyzx+Zj3rugUditlQ/59AtIJTIJWw2yFWzjuSeJ1/ qVvxZGqipIUjg5y2CH5vtzU1yWFXmv5onofJq8yBIgIEmuEhpFogTZk9BZ0uSgyocP7C9y/LpOq F/oLMHF5p/Anub9mI1YSbd8naFzABAI4XNQb4vz6in6FVGqOArBMW/01/WN8bpsmCNixvKdRX7P CH+AxJMakf21IYBiDbFzzaM+8jxdEHg8q+4GBtLQkAt5kIpmdWJMvIsh+6Y/pqv/Fhh2mcEgorg Sf2/Htfooy+EVe9Ng/YarsnZ8CftEbUPS2ekc8wsAIz53vrcggLgQxdU+SpkM5JBTLPaT21B+9s M1xVdK2xhVNHQ== X-Received: by 2002:a05:600c:c4ac:b0:499:a5fc:2087 with SMTP id 5b1f17b1804b1-49b91c20e36mr318733065e9.6.1788121031326; Sun, 30 Aug 2026 13:17:11 -0700 (PDT) Received: from localhost (ip87-106-108-193.pbiaas.com. [87.106.108.193]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49cd2922ebdsm100498265e9.3.2026.08.30.13.17.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 30 Aug 2026 13:17:11 -0700 (PDT) From: =?UTF-8?q?G=C3=BCnther=20Noack?= To: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= Cc: Matthieu Baerts , Mat Martineau , Geliang Tang , Mikhail Ivanov , mptcp@lists.linux.dev, netdev@vger.kernel.org, linux-security-module@vger.kernel.org, =?UTF-8?q?G=C3=BCnther=20Noack?= Subject: [PATCH 6/6] landlock: Document MPTCP access rights Date: Sun, 30 Aug 2026 22:16:50 +0200 Message-ID: <20260830201650.67050-7-gnoack3000@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260830201650.67050-1-gnoack3000@gmail.com> References: <20260830201650.67050-1-gnoack3000@gmail.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Describe LANDLOCK_ACCESS_NET_BIND_MPTCP and LANDLOCK_ACCESS_NET_CONNECT_MPTCP in the userspace API documentation. Extend the tutorial to handle the new access rights. Describe MPTCP restrictions in "previous limitations". Signed-off-by: Günther Noack --- Documentation/userspace-api/landlock.rst | 27 +++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst index 84cb7bf6b3ed..8bd99430514b 100644 --- a/Documentation/userspace-api/landlock.rst +++ b/Documentation/userspace-api/landlock.rst @@ -40,7 +40,7 @@ Filesystem rules and the related filesystem actions are defined with `filesystem access rights`. -Network rules (since ABI v4 for TCP and v10 for UDP) +Network rules (since ABI v4 for TCP, v10 for UDP, and v12 for MPTCP) For these rules, the object is a TCP or UDP port, and the related actions are defined with `network access rights`. @@ -51,7 +51,7 @@ We first need to define the ruleset that will contain our rules. For this example, the ruleset will contain rules that only allow some filesystem read actions and some specific UDP and TCP actions. Filesystem -write actions and other TCP/UDP actions will be denied. +write actions and other TCP/UDP/MPTCP actions will be denied. The ruleset then needs to handle all these kinds of actions. This is required for backward and forward compatibility (i.e. the kernel and user @@ -83,7 +83,9 @@ to be explicit about the denied-by-default access rights. LANDLOCK_ACCESS_NET_BIND_TCP | LANDLOCK_ACCESS_NET_CONNECT_TCP | LANDLOCK_ACCESS_NET_BIND_UDP | - LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP, + LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP | + LANDLOCK_ACCESS_NET_BIND_MPTCP | + LANDLOCK_ACCESS_NET_CONNECT_MPTCP, .scoped = LANDLOCK_SCOPE_ABSTRACT_UNIX_SOCKET | LANDLOCK_SCOPE_SIGNAL, @@ -140,6 +142,12 @@ version, and only use the available subset of access rights: ruleset_attr.handled_access_net &= ~(LANDLOCK_ACCESS_NET_BIND_UDP | LANDLOCK_ACCESS_NET_CONNECT_SEND_UDP); + __attribute__((fallthrough)); + case 10 ... 11: + /* Removes LANDLOCK_ACCESS_NET_*_MPTCP for ABI < 12 */ + ruleset_attr.handled_access_net &= + ~(LANDLOCK_ACCESS_NET_BIND_MPTCP | + LANDLOCK_ACCESS_NET_CONNECT_MPTCP); } This enables the creation of an inclusive ruleset that will contain our rules. @@ -834,6 +842,19 @@ with ``LANDLOCK_RESTRICT_SELF_TSYNC``, no_new_privs is set on all threads of the process. As explained in the tutorial above, leaving no_new_privs unset is risky even when Landlock does not require it. +MPTCP bind and connect (ABI < 12) +--------------------------------- + +Starting with the Landlock ABI version 12, it is possible to restrict MPTCP +bind and connect actions with the ``LANDLOCK_ACCESS_NET_BIND_MPTCP`` and +``LANDLOCK_ACCESS_NET_CONNECT_MPTCP`` access rights. + +Because MPTCP works on the same TCP port number space as plain TCP, it +is recommended that rulesets denying TCP operations should also deny +the equivalent MPTCP operations. In particular, a listening port +created through an ``IPPROTO_MPTCP`` socket is compatible with plain +TCP clients as well. + .. _kernel_support: Kernel support -- 2.55.0