5/20/2022 1:48 PM, Mickaël Salaün пишет:
Hi,
Regarding future plan to support UDP, it may not be possible to
efficiently restrict sending on a port or receiving on a port because of
the non-connnected state of UDP sockets. Indeed, when setting up a
socket to send a packet on a specified port, we (automatically or
manually) have a receiving port configured and this socket can be used
to receive any UDP packet. An UDP socket could be restricted to only
send/write or to receive/read from a specific port, but this would
probably not be as useful as the TCP restrictions. That could look like
RECEIVE_UDP and SEND_UDP access-rights but the LSM implementation would
be more complex because of the socket/FD tracking. Moreover, the
performance impact could be more important for every read and write
syscall (whatever the FD type).
Any opinion?
You are right about non-connected nature of UDP sockets and
landlocking them like TCP ones would have performance impact.
I'm thinking about a "connected" UDP socket.
It's possible call connect() for a UDP socket. But this does not result
in anything like a TCP connection: There is no three-way handshake.
Instead, the kernel just checks for any immediate errors (e.g., an
obviously unreachable destination), records the IP address and port
number of the peer (from the socket address structure passed to
connect), and returns immediately to the calling process. In this case
UDP socket is pseudo-connected and stores peer IP addrsss and port from
connect(). The application calls connect(), specifies the IP address and
port number of its peer. It then uses read() and write() yo exchange
data with the peer. Datagrams arriving from any other IP address or port
are not passed to the connected socket because either the source IP
address or source UDP port does not match the protocol address to which
the socket is connected. These datagrams could be delivered to some
other UDP socket on the host. If there is no other matching socket for
the arriving datagram, UDP will discard it and generate an ICMP ‘‘port
unreachable’’ error. In summary, we can say that a UDP client or server
can call connect only if that process uses the UDP socket to communicate
with exactly one peer. Normally, it is a UDP client that calls connect,
but there are applications in which the UDP server communicates with a
single client for a long duration (e.g., TFTP); in this case, both the
client and server can call connect. [1]
In case if a "connected", or lets call it "pseudo-connected", UPD socket
there is no performance impact on write(), read() system calls, cause we
could use the same hooks bind() and connect() like for TCP one.
What do you think? Please share your opinion?
[1] "Unix Network Programming, The sockets Networling API." by W.Richard
Stevens.
Regards,
Mickaël
On 16/05/2022 17:20, Konstantin Meskhidze wrote:
Hi,
This is a new V5 patch related to Landlock LSM network confinement.
It is based on the latest landlock-wip branch on top of v5.18-rc5:
https://git.kernel.org/pub/scm/linux/kernel/git/mic/linux.git/log/?h=landlock-wip
It brings refactoring of previous patch version V4.
Added additional selftests for IP6 network families and network
namespace.
Added TCP sockets confinement support in sandboxer demo.
All test were run in QEMU evironment and compiled with
-static flag.
1. network_test: 13/13 tests passed.
2. base_test: 7/7 tests passed.
3. fs_test: 59/59 tests passed.
4. ptrace_test: 8/8 tests passed.
Still have issue with base_test were compiled without -static flag
(landlock-wip branch without network support)
1. base_test: 6/7 tests passed.
Error:
# RUN global.inconsistent_attr ...
# base_test.c:54:inconsistent_attr:Expected ENOMSG (42) == errno (22)
# inconsistent_attr: Test terminated by assertion
# FAIL global.inconsistent_attr
not ok 1 global.inconsistent_attr
LCOV - code coverage report:
Hit Total Coverage
Lines: 952 1010 94.3 %
Functions: 79 82 96.3 %
Previous versions:
v4:
https://lore.kernel.org/linux-security-module/20220309134459.6448-1-konstantin.meskhidze@xxxxxxxxxx/
v3:
https://lore.kernel.org/linux-security-module/20220124080215.265538-1-konstantin.meskhidze@xxxxxxxxxx/
v2:
https://lore.kernel.org/linux-security-module/20211228115212.703084-1-konstantin.meskhidze@xxxxxxxxxx/
v1:
https://lore.kernel.org/linux-security-module/20211210072123.386713-1-konstantin.meskhidze@xxxxxxxxxx/
Konstantin Meskhidze (15):
landlock: access mask renaming
landlock: landlock_find/insert_rule refactoring
landlock: merge and inherit function refactoring
landlock: helper functions refactoring
landlock: landlock_add_rule syscall refactoring
landlock: user space API network support
landlock: add support network rules
landlock: TCP network hooks implementation
seltests/landlock: add tests for bind() hooks
seltests/landlock: add tests for connect() hooks
seltests/landlock: connect() with AF_UNSPEC tests
seltests/landlock: rules overlapping test
seltests/landlock: ruleset expanding test
seltests/landlock: invalid user input data test
samples/landlock: adds network demo
include/uapi/linux/landlock.h | 48 +
samples/landlock/sandboxer.c | 105 ++-
security/landlock/Kconfig | 1 +
security/landlock/Makefile | 2 +
security/landlock/fs.c | 169 +---
security/landlock/limits.h | 8 +-
security/landlock/net.c | 159 ++++
security/landlock/net.h | 25 +
security/landlock/ruleset.c | 481 ++++++++--
security/landlock/ruleset.h | 102 +-
security/landlock/setup.c | 2 +
security/landlock/syscalls.c | 173 ++--
tools/testing/selftests/landlock/base_test.c | 4 +-
tools/testing/selftests/landlock/common.h | 9 +
tools/testing/selftests/landlock/config | 5 +-
tools/testing/selftests/landlock/fs_test.c | 10 -
tools/testing/selftests/landlock/net_test.c | 935 +++++++++++++++++++
17 files changed, 1925 insertions(+), 313 deletions(-)
create mode 100644 security/landlock/net.c
create mode 100644 security/landlock/net.h
create mode 100644 tools/testing/selftests/landlock/net_test.c
--
2.25.1
.
