From: "Günther Noack" <gnoack3000@gmail.com>
To: Justin Suess <utilityemal77@gmail.com>
Cc: "Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
"Kuniyuki Iwashima" <kuniyu@google.com>,
"Simon Horman" <horms@kernel.org>,
"Mickaël Salaün" <mic@digikod.net>,
"Günther Noack" <gnoack@google.com>,
linux-security-module@vger.kernel.org,
"Tingmao Wang" <m@maowtm.org>,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] lsm: Add hook unix_path_connect
Date: Thu, 1 Jan 2026 13:13:37 +0100 [thread overview]
Message-ID: <20260101.f6d0f71ca9bb@gnoack.org> (raw)
In-Reply-To: <20251231213314.2979118-2-utilityemal77@gmail.com>
On Wed, Dec 31, 2025 at 04:33:14PM -0500, Justin Suess wrote:
> 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.
>
> Signed-off-by: Justin Suess <utilityemal77@gmail.com>
> Cc: Günther Noack <gnoack3000@gmail.com>
> ---
> include/linux/lsm_hook_defs.h | 1 +
> include/linux/security.h | 6 ++++++
> net/unix/af_unix.c | 8 ++++++++
> security/security.c | 16 ++++++++++++++++
> 4 files changed, 31 insertions(+)
>
> diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
> index 8c42b4bde09c..a42d1aaf3b8a 100644
> --- a/include/linux/lsm_hook_defs.h
> +++ b/include/linux/lsm_hook_defs.h
> @@ -318,6 +318,7 @@ LSM_HOOK(int, 0, watch_key, struct key *key)
> #endif /* CONFIG_SECURITY && CONFIG_KEY_NOTIFICATIONS */
>
> #ifdef CONFIG_SECURITY_NETWORK
> +LSM_HOOK(int, 0, unix_path_connect, const struct path *path)
You are placing this guarded by CONFIG_SECURITY_NETWORK, but there is
also CONFIG_SECURITY_PATH. Should it be guarded by both?
> LSM_HOOK(int, 0, unix_stream_connect, struct sock *sock, struct sock *other,
> struct sock *newsk)
> LSM_HOOK(int, 0, unix_may_send, struct socket *sock, struct socket *other)
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 83a646d72f6f..ab66f22f7e5a 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -1638,6 +1638,7 @@ static inline int security_watch_key(struct key *key)
>
> #ifdef CONFIG_SECURITY_NETWORK
>
> +int security_unix_path_connect(const struct path *path);
> int security_netlink_send(struct sock *sk, struct sk_buff *skb);
> int security_unix_stream_connect(struct sock *sock, struct sock *other, struct sock *newsk);
> int security_unix_may_send(struct socket *sock, struct socket *other);
> @@ -1699,6 +1700,11 @@ static inline int security_netlink_send(struct sock *sk, struct sk_buff *skb)
> return 0;
> }
>
> +static inline int security_unix_path_connect(const struct path *path)
> +{
> + return 0;
> +}
> +
> static inline int security_unix_stream_connect(struct sock *sock,
> struct sock *other,
> struct sock *newsk)
> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> index 55cdebfa0da0..af1a6083a69b 100644
> --- a/net/unix/af_unix.c
> +++ b/net/unix/af_unix.c
> @@ -1226,6 +1226,14 @@ static struct sock *unix_find_bsd(struct sockaddr_un *sunaddr, int addr_len,
> if (!S_ISSOCK(inode->i_mode))
> goto path_put;
>
> + /*
> + * We call the hook because we know that the inode is a socket
> + * and we hold a valid reference to it via the path.
> + */
> + err = security_unix_path_connect(&path);
> + if (err)
> + goto path_put;
In this place, the hook call is done also for the coredump socket.
The coredump socket is a system-wide setting, and it feels weird to me
that unprivileged processes should be able to inhibit that connection?
> +
> sk = unix_find_socket_byinode(inode);
> if (!sk)
> goto path_put;
> diff --git a/security/security.c b/security/security.c
> index 31a688650601..17af5d0ddf28 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -4047,6 +4047,22 @@ int security_unix_stream_connect(struct sock *sock, struct sock *other,
> }
> EXPORT_SYMBOL(security_unix_stream_connect);
>
> +/*
> + * security_unix_path_connect() - Check if a named AF_UNIX socket can connect
> + * @path: Path of the socket being connected to
^
mega-nit: lowercase for consistency
> + *
> + * This hook is called to check permissions before connecting to a named
> + * AF_UNIX socket. This is necessary because it was not possible to check the
> + * VFS inode of the target socket before the connection is made.
I'd drop the last sentence; the defense why this is necessary can go
in the commit message, and once we have a call-site for the hook,
someone browsing the kernel code can look up what it is used for.
> + *
> + * Return: Returns 0 if permission is granted.
> + */
> +int security_unix_path_connect(const struct path *path)
> +{
> + return call_int_hook(unix_path_connect, path);
> +}
> +EXPORT_SYMBOL(security_unix_path_connect);
> +
> /**
> * security_unix_may_send() - Check if AF_UNIX socket can send datagrams
> * @sock: originating sock
> --
> 2.51.0
>
next prev parent reply other threads:[~2026-01-01 12:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-31 21:33 [RFC PATCH 0/1] lsm: Add hook unix_path_connect Justin Suess
2025-12-31 21:33 ` [RFC PATCH 1/1] " Justin Suess
2026-01-01 12:13 ` Günther Noack [this message]
2026-01-01 19:45 ` [RFC PATCH 0/1] " Justin Suess
2026-01-01 23:11 ` Tingmao Wang
2026-01-01 23:40 ` Justin Suess
2026-01-01 9:46 ` [syzbot ci] " syzbot ci
2026-01-01 11:56 ` [RFC PATCH 0/1] " Günther Noack
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=20260101.f6d0f71ca9bb@gnoack.org \
--to=gnoack3000@gmail.com \
--cc=gnoack@google.com \
--cc=horms@kernel.org \
--cc=jmorris@namei.org \
--cc=kuniyu@google.com \
--cc=linux-security-module@vger.kernel.org \
--cc=m@maowtm.org \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=utilityemal77@gmail.com \
/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;
as well as URLs for NNTP newsgroup(s).