Re: [PATCH bpf-next v9 4/9] bpf: Implement cgroup sockaddr hooks for unix sockets

[Kuniyuki Iwashima <kuniyu@amazon.com>]

From: Daan De Meyer <daan.j.demeyer@gmail.com>
Date: Fri,  6 Oct 2023 09:44:58 +0200
> These hooks allows intercepting connect(), getsockname(),
> getpeername(), sendmsg() and recvmsg() for unix sockets. The unix
> socket hooks get write access to the address length because the
> address length is not fixed when dealing with unix sockets and
> needs to be modified when a unix socket address is modified by
> the hook. Because abstract socket unix addresses start with a
> NUL byte, we cannot recalculate the socket address in kernelspace
> after running the hook by calculating the length of the unix socket
> path using strlen().
> 
> These hooks can be used when users want to multiplex syscall to a
> single unix socket to multiple different processes behind the scenes
> by redirecting the connect() and other syscalls to process specific
> sockets.
> 
> We do not implement support for intercepting bind() because when
> using bind() with unix sockets with a pathname address, this creates
> an inode in the filesystem which must be cleaned up. If we rewrite
> the address, the user might try to clean up the wrong file, leaking
> the socket in the filesystem where it is never cleaned up. Until we
> figure out a solution for this (and a use case for intercepting bind()),
> we opt to not allow rewriting the sockaddr in bind() calls.
> 
> We also implement recvmsg() support for connected streams so that
> after a connect() that is modified by a sockaddr hook, any corresponding
> recmvsg() on the connected socket can also be modified to make the
> connected program think it is connected to the "intended" remote.
> 
> Signed-off-by: Daan De Meyer <daan.j.demeyer@gmail.com>

Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>