All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

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

Thread overview: 20+ 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-07 21:43       ` Paul Moore
2026-01-01  9:46 ` [syzbot ci] " syzbot ci
2026-01-01 11:56 ` [RFC PATCH 0/1] " Günther Noack
2026-01-05  7:46 ` Kuniyuki Iwashima
2026-01-05 11:04   ` Günther Noack
2026-01-05 16:04     ` Justin Suess
2026-01-07  7:33     ` Kuniyuki Iwashima
2026-01-07 12:19       ` Justin Suess
2026-01-07 16:57         ` Günther Noack
2026-01-07 12:49       ` Günther Noack
2026-01-08 10:17         ` Kuniyuki Iwashima
2026-01-08 18:42           ` Mickaël Salaün
2026-01-08 21:30           ` Günther Noack
2026-01-07 21:54 ` Paul Moore

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.