[PATCH 1/2] landlock: Add hook on socket_listen()

Mickaël Salaün mic at digikod.net
Tue Apr 30 16:52:12 UTC 2024


On Tue, Apr 30, 2024 at 03:36:30PM +0200, Mickaël Salaün wrote:
> On Mon, Apr 08, 2024 at 05:47:46PM +0800, Ivanov Mikhail wrote:
> > Make hook for socket_listen(). It will check that the socket protocol is
> > TCP, and if the socket's local port number is 0 (which means,
> > that listen(2) was called without any previous bind(2) call),
> > then listen(2) call will be legitimate only if there is a rule for bind(2)
> > allowing binding to port 0 (or if LANDLOCK_ACCESS_NET_BIND_TCP is not
> > supported by the sandbox).
> 
> Thanks for this patch and sorry for the late full review.  The code is
> good overall.
> 
> We should either consider this patch as a fix or add a new flag/access
> right to Landlock syscalls for compatibility reason.  I think this
> should be a fix.  Calling listen(2) without a previous call to bind(2)
> is a corner case that we should properly handle.  The commit message
> should make that explicit and highlight the goal of the patch: first
> explain why, and then how.
> 
> We also need to update the user documentation to explain that
> LANDLOCK_ACCESS_NET_BIND_TCP also handles this case.
> 
> > 
> > Create a new check_access_socket() function to prevent useless copy paste.
> > It should be called by hook handlers after they perform special checks and
> > calculate socket port value.
> 
> You can add this tag:
> Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect")
> 
> > 
> > Signed-off-by: Ivanov Mikhail <ivanov.mikhail1 at huawei-partners.com>
> > Reviewed-by: Konstantin Meskhidze <konstantin.meskhidze at huawei.com>
> > ---
> >  security/landlock/net.c | 104 +++++++++++++++++++++++++++++++++-------
> >  1 file changed, 88 insertions(+), 16 deletions(-)


> > +		if (inet_sk(sock->sk)->inet_num != 0)
> 
> Why do we want to allow listen() on any socket that is binded?

Please ignore this comment. I was initially thinking about a new access
right, which would be good to have anyway, but with another series.



More information about the Linux-security-module-archive mailing list