mirror of
https://github.com/torvalds/linux.git
synced 2024-12-01 16:41:39 +00:00
fff69fb03d
Add network rules support in the ruleset management helpers and the landlock_create_ruleset() syscall. Extend user space API to support network actions: * Add new network access rights: LANDLOCK_ACCESS_NET_BIND_TCP and LANDLOCK_ACCESS_NET_CONNECT_TCP. * Add a new network rule type: LANDLOCK_RULE_NET_PORT tied to struct landlock_net_port_attr. The allowed_access field contains the network access rights, and the port field contains the port value according to the controlled protocol. This field can take up to a 64-bit value but the maximum value depends on the related protocol (e.g. 16-bit value for TCP). Network port is in host endianness [1]. * Add a new handled_access_net field to struct landlock_ruleset_attr that contains network access rights. * Increment the Landlock ABI version to 4. Implement socket_bind() and socket_connect() LSM hooks, which enable to control TCP socket binding and connection to specific ports. Expand access_masks_t from u16 to u32 to be able to store network access rights alongside filesystem access rights for rulesets' handled access rights. Access rights are not tied to socket file descriptors but checked at bind() or connect() call time against the caller's Landlock domain. For the filesystem, a file descriptor is a direct access to a file/data. However, for network sockets, we cannot identify for which data or peer a newly created socket will give access to. Indeed, we need to wait for a connect or bind request to identify the use case for this socket. Likewise a directory file descriptor may enable to open another file (i.e. a new data item), but this opening is also restricted by the caller's domain, not the file descriptor's access rights [2]. [1] https://lore.kernel.org/r/278ab07f-7583-a4e0-3d37-1bacd091531d@digikod.net [2] https://lore.kernel.org/r/263c1eb3-602f-57fe-8450-3f138581bee7@digikod.net Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com> Link: https://lore.kernel.org/r/20231026014751.414649-9-konstantin.meskhidze@huawei.com [mic: Extend commit message, fix typo in comments, and specify endianness in the documentation] Co-developed-by: Mickaël Salaün <mic@digikod.net> Signed-off-by: Mickaël Salaün <mic@digikod.net>
23 lines
930 B
Plaintext
23 lines
930 B
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
config SECURITY_LANDLOCK
|
|
bool "Landlock support"
|
|
depends on SECURITY
|
|
select SECURITY_NETWORK
|
|
select SECURITY_PATH
|
|
help
|
|
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().
|
|
|
|
See Documentation/userspace-api/landlock.rst for further information.
|
|
|
|
If you are unsure how to answer this question, answer N. Otherwise,
|
|
you should also prepend "landlock," to the content of CONFIG_LSM to
|
|
enable Landlock at boot time.
|