On 1/15/26 05:10, Günther Noack wrote:

On Tue, Jan 13, 2026 at 06:27:15PM -0500, Paul Moore wrote:

quoted

On Tue, Jan 13, 2026 at 4:34 AM Christian Brauner [off-list ref] wrote:

quoted

On Sat, Jan 10, 2026 at 03:32:57PM +0100, Günther Noack wrote:

quoted

From: Justin Suess <redacted>

Adds an LSM hook unix_path_connect.

This hook is called to check the path of a named unix socket before a
connection is initiated.

Cc: Günther Noack <redacted>
Signed-off-by: Justin Suess <redacted>
---
 include/linux/lsm_hook_defs.h |  4 ++++
 include/linux/security.h      | 11 +++++++++++
 net/unix/af_unix.c            |  9 +++++++++
 security/security.c           | 20 ++++++++++++++++++++
 4 files changed, 44 insertions(+)

...

...

* Some properties of the resolved socket are still observable to
  userspace:

  When we only pass the path to a later LSM hook, there are a variety
  of additional error case checks in af_unix.c which are based on the
  "other" socket which we looked up through the path.  Examples:

  * was other shutdown(2)? (ECONNREFUSED on connect or EPIPE on dgram_sendmsg)
  * does other support SO_PASSRIGHTS (fd passing)? (EPERM on dgram_sendmsg)
  * would sendmsg pass sk_filter() (on dgram_sendmsg)

  For a LSM policy that is supposed to restrict the resolution of a
  UNIX socket by path, I would not expect such properties of the
  resolved socket to be observable?

  (And we also can't fix this up in the LSM by returning a matching
  error code, because at least unix_dgram_sendmsg() returns multiple
  different error codes in these error cases.)

  I would prefer if the correctness of our LSM did not depend on
  keeping track of the error scenarios in af_unix.c.  This seems
  brittle.

Indeed so.

Overall, I am not convinced that using pre-existing hooks is the right
way and I would prefer the approach where we have a more dedicated LSM
hook for the path lookup.

Does that seem reasonable?  Let me know what you think.

–Günther

Having a dedicated LSM hook for all path lookups is definitely my
preferred approach.  Could this allow limiting directory traversal
as well?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)