public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: "Günther Noack" <gnoack3000@gmail.com>
Cc: "Matthieu Buffet" <matthieu@buffet.re>,
	"Günther Noack" <gnoack@google.com>,
	linux-security-module@vger.kernel.org,
	"Mikhail Ivanov" <ivanov.mikhail1@huawei-partners.com>,
	konstantin.meskhidze@huawei.com, netdev@vger.kernel.org
Subject: Re: [RFC PATCH v3 0/8] landlock: Add UDP access control support
Date: Mon, 12 Jan 2026 17:03:30 +0100	[thread overview]
Message-ID: <20260112.Bee3chi7xa8D@digikod.net> (raw)
In-Reply-To: <20260111.f025d6aefcf4@gnoack.org>

On Sun, Jan 11, 2026 at 10:23:16PM +0100, Günther Noack wrote:
> Hello Matthieu!
> 
> On Fri, Dec 12, 2025 at 05:36:56PM +0100, Matthieu Buffet wrote:
> > Here is v3 of UDP support for Landlock. My apologies for the delay, I've
> > had to deal with unrelated problems. All feedback from v1/v2 should be
> > merged, thanks again for taking the time to review them.
> 
> Good to see the patch again. :)
> 
> Apologies for review delay as well.  There are many Landlock reviews
> in flight at the moment, it might take some time to catch up with all
> of them.
> 
> FYI: In [1], I have been sending a patch for controlling UNIX socket
> lookup, which is restricting connect() and sendmsg() operations for
> UNIX domain sockets of types SOCK_STREAM, SOCK_DGRAM and
> SOCK_SEQPACKET.  I am bringing it up because it feels that the
> semantics for the UDP and UNIX datagram access rights hook in similar
> places and therefore should work similarly?

Thanks for bringing this up.

> 
> In the current UNIX socket patch set (v2), there is only one Landlock
> access right which controls both connect() and sendmsg() when they are
> done on a UNIX datagram socket.  This feels natural to be, because you
> can reach the same recipient address whether that is done with
> connect() or with sendmsg()...?
> 
> (Was there a previous discussion where it was decided that these
> should be two different access rights for UDP sockets and UNIX dgram
> sockets?)

The rationale for these three access rights (connect, bind, and sendto)
is in the related commit message and it was discussed here:
https://lore.kernel.org/all/3631edfd-7f41-4ff1-9f30-20dcaa17b726@buffet.re/

Access rights for UNIX sockets can be simpler because we always know the
peer process, which is not the case for IP requests.  For the later,
being able to filter on the socket type can help.

> 
> [1] https://lore.kernel.org/all/20260101134102.25938-1-gnoack3000@gmail.com/
> 
> Thanks,
> –Günther
> 

  reply	other threads:[~2026-01-12 16:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-12 16:36 [RFC PATCH v3 0/8] landlock: Add UDP access control support Matthieu Buffet
2025-12-12 16:36 ` [RFC PATCH v3 1/8] landlock: Minor reword of docs for TCP access rights Matthieu Buffet
2025-12-12 16:36 ` [RFC PATCH v3 2/8] landlock: Refactor TCP socket type check Matthieu Buffet
2025-12-12 16:36 ` [RFC PATCH v3 3/8] landlock: Add UDP bind+connect access control Matthieu Buffet
2025-12-12 16:37 ` [RFC PATCH v3 4/8] selftests/landlock: Add UDP bind/connect tests Matthieu Buffet
2025-12-12 16:37 ` [RFC PATCH v3 5/8] landlock: Add UDP sendmsg access control Matthieu Buffet
2025-12-12 16:37 ` [RFC PATCH v3 6/8] selftests/landlock: Add tests for UDP sendmsg Matthieu Buffet
2026-02-01 16:19   ` Tingmao Wang
2025-12-12 16:37 ` [RFC PATCH v3 7/8] samples/landlock: Add sandboxer UDP access control Matthieu Buffet
2025-12-12 16:37 ` [RFC PATCH v3 8/8] landlock: Add documentation for UDP support Matthieu Buffet
2026-01-11 21:23 ` [RFC PATCH v3 0/8] landlock: Add UDP access control support Günther Noack
2026-01-12 16:03   ` Mickaël Salaün [this message]
2026-02-14 10:34 ` Mickaël Salaün

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=20260112.Bee3chi7xa8D@digikod.net \
    --to=mic@digikod.net \
    --cc=gnoack3000@gmail.com \
    --cc=gnoack@google.com \
    --cc=ivanov.mikhail1@huawei-partners.com \
    --cc=konstantin.meskhidze@huawei.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthieu@buffet.re \
    --cc=netdev@vger.kernel.org \
    /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