From: Mikhail Ivanov <ivanov.mikhail1@huawei-partners.com>
To: "Mickaël Salaün" <mic@digikod.net>
Cc: <gnoack@google.com>, <willemdebruijn.kernel@gmail.com>,
<matthieu@buffet.re>, <linux-security-module@vger.kernel.org>,
<netdev@vger.kernel.org>, <netfilter-devel@vger.kernel.org>,
<yusongping@huawei.com>, <artem.kuzin@huawei.com>,
<konstantin.meskhidze@huawei.com>
Subject: Re: [RFC PATCH v4 00/19] Support socket access-control
Date: Tue, 14 Apr 2026 22:45:14 +0300 [thread overview]
Message-ID: <acc8ac68-d581-b5b1-afce-95d304b943d2@huawei-partners.com> (raw)
In-Reply-To: <20260414.thaeki1iigeM@digikod.net>
On 4/14/2026 5:27 PM, Mickaël Salaün wrote:
> On Mon, Apr 13, 2026 at 08:11:48PM +0300, Mikhail Ivanov wrote:
>> On 4/8/2026 1:26 PM, Mickaël Salaün wrote:
>>> Hi Mikhail,
>>
>> Hi!
>>
>>>
>>> On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
>>>> Hello! This is v4 RFC patch dedicated to socket protocols restriction.
>>>>
>>>> It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
>>>> kernel version.
>>>>
>>>> Objective
>>>> =========
>>>> Extend Landlock with a mechanism to restrict any set of protocols in
>>>> a sandboxed process.
>>>>
>>>> Closes: https://github.com/landlock-lsm/linux/issues/6
>>>>
>>>> Motivation
>>>> ==========
>>>> Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
>>>> fine-grained control of actions for a specific protocol. Any action or
>>>> protocol that is not supported by this rule can not be controlled. As a
>>>> result, protocols for which fine-grained control is not supported can be
>>>> used in a sandboxed system and lead to vulnerabilities or unexpected
>>>> behavior.
>>>>
>>>> Controlling the protocols used will allow to use only those that are
>>>> necessary for the system and/or which have fine-grained Landlock control
>>>> through others types of rules (e.g. TCP bind/connect control with
>>>> `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
>>>> `LANDLOCK_RULE_PATH_BENEATH`).
>>>>
>>>> Consider following examples:
>>>> * Server may want to use only TCP sockets for which there is fine-grained
>>>> control of bind(2) and connect(2) actions [1].
>>>> * System that does not need a network or that may want to disable network
>>>> for security reasons (e.g. [2]) can achieve this by restricting the use
>>>> of all possible protocols.
>>>>
>>>> [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
>>>> [2] https://cr.yp.to/unix/disablenetwork.html
>>>>
>>>> Implementation
>>>> ==============
>>>> This patchset adds control over the protocols used by implementing a
>>>> restriction of socket creation. This is possible thanks to the new type
>>>> of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
>>>> sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
>>>> corresponds to user space sockets creation. The key in this rule
>>>> corresponds to communication protocol signature from socket(2) syscall.
>>>
>>> FYI, I sent a new patch series that adds a handled_perm field to
>>> rulesets:
>>> https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
>>> See also the rationale:
>>> https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
>>>
>>> I think that would work well with the socket creation permission. WDYT?
>>
>> Agreed. AFAICS restrictions of protocols used for communication (eg.TCP)
>> will complement restriction of network namespace which sandboxed process
>> is pinned by LANDLOCK_PERM_NAMESPACE_ENTER permission.
>
> I mean that socket creation restriction should use the same handled_perm
> interface e.g. add a LANDLOCK_PERM_SOCKET_CREATE right with related
> LANDLOCK_RULE_SOCKET rule type.
Oh, I see your point.
>
> With the first RFC for handled_perm, the related rules (e.g. struct
> landlock_socket_attr) don't have an allowed_access field but an
> allowed_perm one instead. The related permission would then be
> LANDLOCK_PERM_SOCKET_CREATE. WDYT?
Of course, thats reasonable. We haven't come up with reasonable ideas of
access rights for LANDLOCK_RULE_SOCKET except socket creation, so
current patchset will fit in handled_perm design very well.
>
>>
>>>
>>> Do you think you'll be able to continue this work or would you like me
>>> or Günther to complete the remaining last bits (while of course keeping
>>> you as the main author)?
>>
>> Sorry for the delay. I will finish and send patch series ASAP.
>
> This new version should then be on top of the Landlock namespace and
> capability patchset to reuse the handled_perm interface. I plan to send
> a new version by the end of the month, but this should not change the
> handled_perm interface.
OK. I will send RFC v5 based on current design for the review anyway.
>
>>
>>>
>>>
>>>>
>>>> The right to create a socket is checked in the LSM hook which is called
>>>> in the __sock_create method. The following user space operations are
>>>> subject to this check: socket(2), socketpair(2), io_uring(7).
>>>>
>>>> `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
>>>> performed by accept(2), because created socket is used for messaging
>>>> between already existing endpoints.
>>>>
>>>> Design discussion
>>>> ===================
>>>> 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
>>>>
>>>> SCTP socket can be connected to a multiple endpoints (one-to-many
>>>> relation). Calling setsockopt(2) on such socket with option
>>>> `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
>>>> UDP socket. This detach is currently restrictable.
>>>>
>>>> Same applies for the socketpair(2) syscall. It was noted that denying
>>>> usage of socketpair(2) in sandboxed environment may be not meaninful [1].
>>>>
>>>> Currently both operations use general socket interface to create sockets.
>>>> Therefore it's not possible to distinguish between socket(2) and those
>>>> operations inside security_socket_create LSM hook which is currently
>>>> used for protocols restriction. Providing such separation may require
>>>> changes in socket layer (eg. in __sock_create) interface which may not be
>>>> acceptable.
>>>>
>>>> [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
>>>>
>>>> Code coverage
>>>> =============
>>>> Code coverage(gcov) report with the launch of all the landlock selftests:
>>>> * security/landlock:
>>>> lines......: 94.0% (1200 of 1276 lines)
>>>> functions..: 95.0% (134 of 141 functions)
>>>>
>>>> * security/landlock/socket.c:
>>>> lines......: 100.0% (56 of 56 lines)
>>>> functions..: 100.0% (5 of 5 functions)
>>>>
>>>> Currently landlock-test-tools fails on mini.kernel_socket test due to lack
>>>> of SMC protocol support.
>>>>
>>>> General changes v3->v4
>>>> ======================
>>>> * Implementation
>>>> * Adds protocol field to landlock_socket_attr.
>>>> * Adds protocol masks support via wildcards values in
>>>> landlock_socket_attr.
>>>> * Changes LSM hook used from socket_post_create to socket_create.
>>>> * Changes protocol ranges acceptable by socket rules.
>>>> * Adds audit support.
>>>> * Changes ABI version to 8.
>>>> * Tests
>>>> * Adds 5 new tests:
>>>> * mini.rule_with_wildcard, protocol_wildcard.access,
>>>> mini.ruleset_with_wildcards_overlap:
>>>> verify rulesets containing rules with wildcard values.
>>>> * tcp_protocol.alias_restriction: verify that Landlock doesn't
>>>> perform protocol mappings.
>>>> * audit.socket_create: tests audit denial logging.
>>>> * Squashes tests corresponding to Landlock rule adding to a single commit.
>>>> * Documentation
>>>> * Refactors Documentation/userspace-api/landlock.rst.
>>>> * Commits
>>>> * Rebases on mic-next.
>>>> * Refactors commits.
>>>>
>>>> Previous versions
>>>> =================
>>>> v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
>>>> v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
>>>> v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
>>>>
>>>> Mikhail Ivanov (19):
>>>> landlock: Support socket access-control
>>>> selftests/landlock: Test creating a ruleset with unknown access
>>>> selftests/landlock: Test adding a socket rule
>>>> selftests/landlock: Testing adding rule with wildcard value
>>>> selftests/landlock: Test acceptable ranges of socket rule key
>>>> landlock: Add hook on socket creation
>>>> selftests/landlock: Test basic socket restriction
>>>> selftests/landlock: Test network stack error code consistency
>>>> selftests/landlock: Test overlapped rulesets with rules of protocol
>>>> ranges
>>>> selftests/landlock: Test that kernel space sockets are not restricted
>>>> selftests/landlock: Test protocol mappings
>>>> selftests/landlock: Test socketpair(2) restriction
>>>> selftests/landlock: Test SCTP peeloff restriction
>>>> selftests/landlock: Test that accept(2) is not restricted
>>>> lsm: Support logging socket common data
>>>> landlock: Log socket creation denials
>>>> selftests/landlock: Test socket creation denial log for audit
>>>> samples/landlock: Support socket protocol restrictions
>>>> landlock: Document socket rule type support
>>>>
>>>> Documentation/userspace-api/landlock.rst | 48 +-
>>>> include/linux/lsm_audit.h | 8 +
>>>> include/uapi/linux/landlock.h | 60 +-
>>>> samples/landlock/sandboxer.c | 118 +-
>>>> security/landlock/Makefile | 2 +-
>>>> security/landlock/access.h | 3 +
>>>> security/landlock/audit.c | 12 +
>>>> security/landlock/audit.h | 1 +
>>>> security/landlock/limits.h | 4 +
>>>> security/landlock/ruleset.c | 37 +-
>>>> security/landlock/ruleset.h | 46 +-
>>>> security/landlock/setup.c | 2 +
>>>> security/landlock/socket.c | 198 +++
>>>> security/landlock/socket.h | 20 +
>>>> security/landlock/syscalls.c | 61 +-
>>>> security/lsm_audit.c | 4 +
>>>> tools/testing/selftests/landlock/base_test.c | 2 +-
>>>> tools/testing/selftests/landlock/common.h | 14 +
>>>> tools/testing/selftests/landlock/config | 47 +
>>>> tools/testing/selftests/landlock/net_test.c | 11 -
>>>> .../selftests/landlock/protocols_define.h | 169 +++
>>>> .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
>>>> 22 files changed, 1990 insertions(+), 46 deletions(-)
>>>> create mode 100644 security/landlock/socket.c
>>>> create mode 100644 security/landlock/socket.h
>>>> create mode 100644 tools/testing/selftests/landlock/protocols_define.h
>>>> create mode 100644 tools/testing/selftests/landlock/socket_test.c
>>>>
>>>>
>>>> base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
>>>> --
>>>> 2.34.1
>>>>
>>>>
>>
prev parent reply other threads:[~2026-04-14 19:45 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 13:46 [RFC PATCH v4 00/19] Support socket access-control Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 01/19] landlock: " Mikhail Ivanov
2025-11-22 10:49 ` Günther Noack
2025-11-22 11:13 ` Mikhail Ivanov
2025-11-22 12:18 ` Günther Noack
2025-11-22 16:51 ` Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 02/19] selftests/landlock: Test creating a ruleset with unknown access Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 03/19] selftests/landlock: Test adding a socket rule Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 04/19] selftests/landlock: Testing adding rule with wildcard value Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 05/19] selftests/landlock: Test acceptable ranges of socket rule key Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 06/19] landlock: Add hook on socket creation Mikhail Ivanov
2025-11-22 11:41 ` Günther Noack
2025-11-22 17:19 ` Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 07/19] selftests/landlock: Test basic socket restriction Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 08/19] selftests/landlock: Test network stack error code consistency Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 09/19] selftests/landlock: Test overlapped rulesets with rules of protocol ranges Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 10/19] selftests/landlock: Test that kernel space sockets are not restricted Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 11/19] selftests/landlock: Test protocol mappings Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 12/19] selftests/landlock: Test socketpair(2) restriction Mikhail Ivanov
2025-11-22 10:16 ` Günther Noack
2025-11-22 10:21 ` Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 13/19] selftests/landlock: Test SCTP peeloff restriction Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 14/19] selftests/landlock: Test that accept(2) is not restricted Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 15/19] lsm: Support logging socket common data Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 16/19] landlock: Log socket creation denials Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 17/19] selftests/landlock: Test socket creation denial log for audit Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 18/19] samples/landlock: Support socket protocol restrictions Mikhail Ivanov
2025-11-18 13:46 ` [RFC PATCH v4 19/19] landlock: Document socket rule type support Mikhail Ivanov
2026-04-08 10:26 ` [RFC PATCH v4 00/19] Support socket access-control Mickaël Salaün
2026-04-13 17:11 ` Mikhail Ivanov
2026-04-14 14:27 ` Mickaël Salaün
2026-04-14 19:45 ` Mikhail Ivanov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acc8ac68-d581-b5b1-afce-95d304b943d2@huawei-partners.com \
--to=ivanov.mikhail1@huawei-partners.com \
--cc=artem.kuzin@huawei.com \
--cc=gnoack@google.com \
--cc=konstantin.meskhidze@huawei.com \
--cc=linux-security-module@vger.kernel.org \
--cc=matthieu@buffet.re \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
--cc=yusongping@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox