[PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Mickaël Salaün]

Because the security_socket_bind and the security_socket_bind hooks are
called before the network stack, it is easy to introduce error code
inconsistencies. Instead of adding new checks to current and future
LSMs, let's fix the related hook instead. The new checks are already
(partially) implemented by SELinux and Landlock, and it should not
change user space behavior but improve error code consistency instead.

The first check is about the minimal sockaddr length according to the
address family. This improves the security of the AF_INET and AF_INET6
sockaddr parsing for current and future LSMs.

The second check is about AF_UNSPEC. This fixes error priority for bind
on PF_INET6 socket when SELinux (and potentially others) is enabled.
Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
error) before checking the family (-EAFNOSUPPORT error). See commit
bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
PF_INET6 socket").

The third check is about consistency between socket family and address
family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
other protocols are checked for now.

These new checks should enable to simplify current LSM implementations,
but we may want to first land this patch on all stable branches.

A following patch adds new tests improving AF_UNSPEC test coverage for
Landlock.

Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Günther Noack <gnoack@google.com>
Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
Signed-off-by: Mickaël Salaün <mic@digikod.net>
---
 security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/security/security.c b/security/security.c
index 7e118858b545..64fe07a73b14 100644
--- a/security/security.c
+++ b/security/security.c
@@ -28,7 +28,9 @@
 #include <linux/xattr.h>
 #include <linux/msg.h>
 #include <linux/overflow.h>
+#include <linux/in.h>
 #include <net/flow.h>
+#include <net/ipv6.h>
 
 /* How many LSMs were built into the kernel? */
 #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
@@ -4415,6 +4417,82 @@ int security_socket_socketpair(struct socket *socka, struct socket *sockb)
 }
 EXPORT_SYMBOL(security_socket_socketpair);
 
+static int validate_inet_addr(struct socket *sock, struct sockaddr *address,
+			      int addrlen, bool bind)
+{
+	const int sock_family = sock->sk->sk_family;
+
+	/* Checks for minimal header length to safely read sa_family. */
+	if (addrlen < offsetofend(typeof(*address), sa_family))
+		return -EINVAL;
+
+	/* Only handle inet sockets for now. */
+	switch (sock_family) {
+	case PF_INET:
+	case PF_INET6:
+		break;
+	default:
+		return 0;
+	}
+
+	/* Checks minimal address length for inet sockets. */
+	switch (address->sa_family) {
+	case AF_UNSPEC: {
+		const struct sockaddr_in *sa_in;
+
+		/* Cf. inet_dgram_connect(), __inet_stream_connect() */
+		if (!bind)
+			return 0;
+
+		if (sock_family == PF_INET6) {
+			/* Length check from inet6_bind_sk() */
+			if (addrlen < SIN6_LEN_RFC2133)
+				return -EINVAL;
+
+			/* Family check from __inet6_bind() */
+			goto err_af;
+		}
+
+		/* Length check from inet_bind_sk() */
+		if (addrlen < sizeof(struct sockaddr_in))
+			return -EINVAL;
+
+		sa_in = (struct sockaddr_in *)address;
+		if (sa_in->sin_addr.s_addr != htonl(INADDR_ANY))
+			goto err_af;
+
+		return 0;
+	}
+	case AF_INET:
+		/* Length check from inet_bind_sk() */
+		if (addrlen < sizeof(struct sockaddr_in))
+			return -EINVAL;
+		break;
+	case AF_INET6:
+		/* Length check from inet6_bind_sk() */
+		if (addrlen < SIN6_LEN_RFC2133)
+			return -EINVAL;
+		break;
+	}
+
+	/*
+	 * Checks sa_family consistency to not wrongfully return -EACCES
+	 * instead of -EINVAL.  Valid sa_family changes are only (from AF_INET
+	 * or AF_INET6) to AF_UNSPEC.
+	 */
+	if (address->sa_family != sock_family)
+		return -EINVAL;
+
+	return 0;
+
+err_af:
+	/* SCTP services expect -EINVAL, others -EAFNOSUPPORT. */
+	if (sock->sk->sk_protocol == IPPROTO_SCTP)
+		return -EINVAL;
+
+	return -EAFNOSUPPORT;
+}
+
 /**
  * security_socket_bind() - Check if a socket bind operation is allowed
  * @sock: socket
@@ -4425,11 +4503,23 @@ EXPORT_SYMBOL(security_socket_socketpair);
  * and the socket @sock is bound to the address specified in the @address
  * parameter.
  *
+ * For security reasons and to get consistent error code whatever LSM are
+ * enabled, we first do the same sanity checks against sockaddr as the ones
+ * done by the network stack (executed after hook).  Currently only AF_UNSPEC,
+ * AF_INET, and AF_INET6 are handled.  Please add support for other family
+ * specificities when handled by an LSM.
+ *
  * Return: Returns 0 if permission is granted.
  */
 int security_socket_bind(struct socket *sock,
 			 struct sockaddr *address, int addrlen)
 {
+	int err;
+
+	err = validate_inet_addr(sock, address, addrlen, true);
+	if (err)
+		return err;
+
 	return call_int_hook(socket_bind, sock, address, addrlen);
 }
 
@@ -4447,6 +4537,12 @@ int security_socket_bind(struct socket *sock,
 int security_socket_connect(struct socket *sock,
 			    struct sockaddr *address, int addrlen)
 {
+	int err;
+
+	err = validate_inet_addr(sock, address, addrlen, false);
+	if (err)
+		return err;
+
 	return call_int_hook(socket_connect, sock, address, addrlen);
 }
 
-- 
2.44.0

[PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests

[Mickaël Salaün]

Test that an IPv6 socket requested to be binded with AF_UNSPEC returns
-EAFNOSUPPORT if the sockaddr length is valid.

Cc: Eric Dumazet <edumazet@google.com>
Cc: Günther Noack <gnoack@google.com>
Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge E. Hallyn <serge@hallyn.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
---
 tools/testing/selftests/landlock/net_test.c | 37 +++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/tools/testing/selftests/landlock/net_test.c b/tools/testing/selftests/landlock/net_test.c
index f21cfbbc3638..f15cf565f856 100644
--- a/tools/testing/selftests/landlock/net_test.c
+++ b/tools/testing/selftests/landlock/net_test.c
@@ -673,6 +673,7 @@ TEST_F(protocol, bind_unspec)
 		.port = self->srv0.port,
 	};
 	int bind_fd, ret;
+	socklen_t inet_len, inet6_len, unix_len;
 
 	if (variant->sandbox == TCP_SANDBOX) {
 		const int ruleset_fd = landlock_create_ruleset(
@@ -736,12 +737,48 @@ TEST_F(protocol, bind_unspec)
 	if (variant->prot.domain == AF_INET) {
 		EXPECT_EQ(-EAFNOSUPPORT, ret);
 	} else {
+		/* The sockaddr length is less than SIN6_LEN_RFC2133. */
 		EXPECT_EQ(-EINVAL, ret)
 		{
 			TH_LOG("Wrong bind error: %s", strerror(errno));
 		}
 	}
 	EXPECT_EQ(0, close(bind_fd));
+
+	/* Stores the minimal sockaddr lengths per family. */
+	self->unspec_srv0.protocol.domain = AF_INET;
+	inet_len = get_addrlen(&self->unspec_srv0, true);
+	self->unspec_srv0.protocol.domain = AF_INET6;
+	inet6_len = get_addrlen(&self->unspec_srv0, true);
+	self->unspec_srv0.protocol.domain = AF_UNIX;
+	unix_len = get_addrlen(&self->unspec_srv0, true);
+	self->unspec_srv0.protocol.domain = AF_UNSPEC;
+
+	/* Checks bind with AF_UNSPEC and less than IPv4 sockaddr length. */
+	bind_fd = socket_variant(&self->srv0);
+	ASSERT_LE(0, bind_fd);
+	ret = bind_variant_addrlen(bind_fd, &self->unspec_srv0, inet_len - 1);
+	EXPECT_EQ(-EINVAL, ret);
+	EXPECT_EQ(0, close(bind_fd));
+
+	/* Checks bind with AF_UNSPEC and IPv6 sockaddr length. */
+	bind_fd = socket_variant(&self->srv0);
+	ASSERT_LE(0, bind_fd);
+	ret = bind_variant_addrlen(bind_fd, &self->unspec_srv0, inet6_len);
+	if (variant->prot.domain == AF_INET ||
+	    variant->prot.domain == AF_INET6) {
+		EXPECT_EQ(-EAFNOSUPPORT, ret);
+	} else {
+		EXPECT_EQ(-EINVAL, ret);
+	}
+	EXPECT_EQ(0, close(bind_fd));
+
+	/* Checks bind with AF_UNSPEC and unix sockaddr length. */
+	bind_fd = socket_variant(&self->srv0);
+	ASSERT_LE(0, bind_fd);
+	ret = bind_variant_addrlen(bind_fd, &self->unspec_srv0, unix_len);
+	EXPECT_EQ(-EINVAL, ret);
+	EXPECT_EQ(0, close(bind_fd));
 }
 
 TEST_F(protocol, connect_unspec)
-- 
2.44.0

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Casey Schaufler]

On 3/27/2024 5:00 AM, Mickaël Salaün wrote:
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.
>
> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>  security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)
>
> diff --git a/security/security.c b/security/security.c
> index 7e118858b545..64fe07a73b14 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -28,7 +28,9 @@
>  #include <linux/xattr.h>
>  #include <linux/msg.h>
>  #include <linux/overflow.h>
> +#include <linux/in.h>
>  #include <net/flow.h>
> +#include <net/ipv6.h>
>  
>  /* How many LSMs were built into the kernel? */
>  #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
> @@ -4415,6 +4417,82 @@ int security_socket_socketpair(struct socket *socka, struct socket *sockb)
>  }
>  EXPORT_SYMBOL(security_socket_socketpair);
>  
> +static int validate_inet_addr(struct socket *sock, struct sockaddr *address,
> +			      int addrlen, bool bind)
> +{
> +	const int sock_family = sock->sk->sk_family;
> +
> +	/* Checks for minimal header length to safely read sa_family. */
> +	if (addrlen < offsetofend(typeof(*address), sa_family))
> +		return -EINVAL;
> +
> +	/* Only handle inet sockets for now. */
> +	switch (sock_family) {
> +	case PF_INET:
> +	case PF_INET6:
> +		break;
> +	default:
> +		return 0;
> +	}

Seems like a clunky way to say:

	if (sock_family != PF_INET && sock_family != PF_INET6)
		return 0;

> +
> +	/* Checks minimal address length for inet sockets. */
> +	switch (address->sa_family) {
> +	case AF_UNSPEC: {
> +		const struct sockaddr_in *sa_in;
> +
> +		/* Cf. inet_dgram_connect(), __inet_stream_connect() */
> +		if (!bind)
> +			return 0;
> +
> +		if (sock_family == PF_INET6) {
> +			/* Length check from inet6_bind_sk() */
> +			if (addrlen < SIN6_LEN_RFC2133)
> +				return -EINVAL;
> +
> +			/* Family check from __inet6_bind() */
> +			goto err_af;
> +		}
> +
> +		/* Length check from inet_bind_sk() */
> +		if (addrlen < sizeof(struct sockaddr_in))
> +			return -EINVAL;
> +
> +		sa_in = (struct sockaddr_in *)address;
> +		if (sa_in->sin_addr.s_addr != htonl(INADDR_ANY))
> +			goto err_af;
> +
> +		return 0;
> +	}
> +	case AF_INET:
> +		/* Length check from inet_bind_sk() */
> +		if (addrlen < sizeof(struct sockaddr_in))
> +			return -EINVAL;
> +		break;
> +	case AF_INET6:
> +		/* Length check from inet6_bind_sk() */
> +		if (addrlen < SIN6_LEN_RFC2133)
> +			return -EINVAL;
> +		break;
> +	}
> +
> +	/*
> +	 * Checks sa_family consistency to not wrongfully return -EACCES
> +	 * instead of -EINVAL.  Valid sa_family changes are only (from AF_INET
> +	 * or AF_INET6) to AF_UNSPEC.
> +	 */
> +	if (address->sa_family != sock_family)
> +		return -EINVAL;
> +
> +	return 0;
> +
> +err_af:
> +	/* SCTP services expect -EINVAL, others -EAFNOSUPPORT. */
> +	if (sock->sk->sk_protocol == IPPROTO_SCTP)
> +		return -EINVAL;
> +
> +	return -EAFNOSUPPORT;
> +}
> +
>  /**
>   * security_socket_bind() - Check if a socket bind operation is allowed
>   * @sock: socket
> @@ -4425,11 +4503,23 @@ EXPORT_SYMBOL(security_socket_socketpair);
>   * and the socket @sock is bound to the address specified in the @address
>   * parameter.
>   *
> + * For security reasons and to get consistent error code whatever LSM are
> + * enabled, we first do the same sanity checks against sockaddr as the ones
> + * done by the network stack (executed after hook).  Currently only AF_UNSPEC,
> + * AF_INET, and AF_INET6 are handled.  Please add support for other family
> + * specificities when handled by an LSM.
> + *
>   * Return: Returns 0 if permission is granted.
>   */
>  int security_socket_bind(struct socket *sock,
>  			 struct sockaddr *address, int addrlen)
>  {
> +	int err;
> +
> +	err = validate_inet_addr(sock, address, addrlen, true);
> +	if (err)
> +		return err;
> +
>  	return call_int_hook(socket_bind, sock, address, addrlen);
>  }
>  
> @@ -4447,6 +4537,12 @@ int security_socket_bind(struct socket *sock,
>  int security_socket_connect(struct socket *sock,
>  			    struct sockaddr *address, int addrlen)
>  {
> +	int err;
> +
> +	err = validate_inet_addr(sock, address, addrlen, false);
> +	if (err)
> +		return err;

The smack_socket_connect() code is among my ugliest. I don't think this
would do any harm, but if you haven't run the Smack test suite you probably
should.

> +
>  	return call_int_hook(socket_connect, sock, address, addrlen);
>  }
>  

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Ivanov Mikhail]

On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
It would probably be better to allow the network stack to perform such
checks before calling LSM hooks. This may lead to following improvements:

1. Fixing extra checks. In the current design, (address)checks are
    performed both in validate_inet_addr() function and
    in network stack methods.

2. The network stack can choose which error cases should not be hidden
    during the LSM access check, and which ones can be.

3. LSM will not be responsible for performing all necessary checks
    for every (necessary) protocol.

This may result in adding new method to socket->ops.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.
>
> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>   security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 96 insertions(+)
>
> diff --git a/security/security.c b/security/security.c
> index 7e118858b545..64fe07a73b14 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -28,7 +28,9 @@
>   #include <linux/xattr.h>
>   #include <linux/msg.h>
>   #include <linux/overflow.h>
> +#include <linux/in.h>
>   #include <net/flow.h>
> +#include <net/ipv6.h>
>   
>   /* How many LSMs were built into the kernel? */
>   #define LSM_COUNT (__end_lsm_info - __start_lsm_info)
> @@ -4415,6 +4417,82 @@ int security_socket_socketpair(struct socket *socka, struct socket *sockb)
>   }
>   EXPORT_SYMBOL(security_socket_socketpair);
>   
> +static int validate_inet_addr(struct socket *sock, struct sockaddr *address,
> +			      int addrlen, bool bind)
> +{
> +	const int sock_family = sock->sk->sk_family;
> +
> +	/* Checks for minimal header length to safely read sa_family. */
> +	if (addrlen < offsetofend(typeof(*address), sa_family))
> +		return -EINVAL;
> +
> +	/* Only handle inet sockets for now. */
> +	switch (sock_family) {
> +	case PF_INET:
> +	case PF_INET6:
> +		break;
> +	default:
> +		return 0;
> +	}
> +
> +	/* Checks minimal address length for inet sockets. */
> +	switch (address->sa_family) {
> +	case AF_UNSPEC: {
> +		const struct sockaddr_in *sa_in;
> +
> +		/* Cf. inet_dgram_connect(), __inet_stream_connect() */
> +		if (!bind)
> +			return 0;
> +
> +		if (sock_family == PF_INET6) {
> +			/* Length check from inet6_bind_sk() */
> +			if (addrlen < SIN6_LEN_RFC2133)
> +				return -EINVAL;
> +
> +			/* Family check from __inet6_bind() */
> +			goto err_af;
> +		}
> +
> +		/* Length check from inet_bind_sk() */
> +		if (addrlen < sizeof(struct sockaddr_in))
> +			return -EINVAL;
> +
> +		sa_in = (struct sockaddr_in *)address;
> +		if (sa_in->sin_addr.s_addr != htonl(INADDR_ANY))
> +			goto err_af;
> +
> +		return 0;
> +	}
> +	case AF_INET:
> +		/* Length check from inet_bind_sk() */
> +		if (addrlen < sizeof(struct sockaddr_in))
> +			return -EINVAL;
> +		break;
> +	case AF_INET6:
> +		/* Length check from inet6_bind_sk() */
> +		if (addrlen < SIN6_LEN_RFC2133)
> +			return -EINVAL;
> +		break;
> +	}
> +
> +	/*
> +	 * Checks sa_family consistency to not wrongfully return -EACCES
> +	 * instead of -EINVAL.  Valid sa_family changes are only (from AF_INET
> +	 * or AF_INET6) to AF_UNSPEC.
> +	 */
> +	if (address->sa_family != sock_family)
> +		return -EINVAL;
> +
> +	return 0;
> +
> +err_af:
> +	/* SCTP services expect -EINVAL, others -EAFNOSUPPORT. */
> +	if (sock->sk->sk_protocol == IPPROTO_SCTP)
> +		return -EINVAL;
> +
> +	return -EAFNOSUPPORT;
> +}
> +
>   /**
>    * security_socket_bind() - Check if a socket bind operation is allowed
>    * @sock: socket
> @@ -4425,11 +4503,23 @@ EXPORT_SYMBOL(security_socket_socketpair);
>    * and the socket @sock is bound to the address specified in the @address
>    * parameter.
>    *
> + * For security reasons and to get consistent error code whatever LSM are
> + * enabled, we first do the same sanity checks against sockaddr as the ones
> + * done by the network stack (executed after hook).  Currently only AF_UNSPEC,
> + * AF_INET, and AF_INET6 are handled.  Please add support for other family
> + * specificities when handled by an LSM.
> + *
>    * Return: Returns 0 if permission is granted.
>    */
>   int security_socket_bind(struct socket *sock,
>   			 struct sockaddr *address, int addrlen)
>   {
> +	int err;
> +
> +	err = validate_inet_addr(sock, address, addrlen, true);
> +	if (err)
> +		return err;
> +
>   	return call_int_hook(socket_bind, sock, address, addrlen);
>   }
>   
> @@ -4447,6 +4537,12 @@ int security_socket_bind(struct socket *sock,
>   int security_socket_connect(struct socket *sock,
>   			    struct sockaddr *address, int addrlen)
>   {
> +	int err;
> +
> +	err = validate_inet_addr(sock, address, addrlen, false);
> +	if (err)
> +		return err;
> +
>   	return call_int_hook(socket_connect, sock, address, addrlen);
>   }
>   

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
<ivanov.mikhail1@huawei-partners.com> wrote:
> On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > Because the security_socket_bind and the security_socket_bind hooks are
> > called before the network stack, it is easy to introduce error code
> > inconsistencies. Instead of adding new checks to current and future
> > LSMs, let's fix the related hook instead. The new checks are already
> > (partially) implemented by SELinux and Landlock, and it should not
> > change user space behavior but improve error code consistency instead.
>
> It would probably be better to allow the network stack to perform such
> checks before calling LSM hooks. This may lead to following improvements:

...

> This may result in adding new method to socket->ops.

I don't think there is a "may result" here, it will *require* a new
socket::proto_ops function (addr_validate?).  If you want to pursue
this with the netdev folks to see if they would be willing to adopt
such an approach I think that would be a great idea.  Just be warned,
there have been difficulties in the past when trying to get any sort
of LSM accommodations from the netdev folks.

-- 
paul-moore.com

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 38854 bytes --]

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

X-sender: <linux-security-module+bounces-2441-steffen.klassert=cunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=c822;steffen.klassert@secunet.com NOTIFY=VER; X-ExtendedProps=AVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ=
X-CreatedBy: MSExchange15
X-HeloDomain: a.mx.secunet.com
X-ExtendedProps: BQBjAAoAi5Hp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgBQAAAAi4oAAAUABAAUIAEAAAAcAAAAc3RlZmZlbi5rbGFzc2VydEBzZWN1bmV0LmNvbQUABgACAAEFACkAAgABDwAJAAAAQ0lBdWRpdGVkAgABBQACAAcAAQAAAAUAAwAHAAAAAAAFAAUAAgABBQBkAA8AAwAAAEh1Yg=
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.36
X-EndOfInjectedXHeaders: 17034
Received: from cas-essen-01.secunet.de (10.53.40.201) by
 mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
 (version=S1_2, cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 22:18:02 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=S1_2,
 cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 22:18:02 +0100
Received: from localhost (localhost [127.0.0.1])
	by a.mx.secunet.com (Postfix) with ESMTP id 83C28208A3
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:18:02 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.051
X-Spam-Level:
X-Spam-Status: No, score=.051 tagged_above=99 required=1
	tests=AYES_00=.9, DKIM_SIGNED=1, DKIM_VALID=.1,
	DKIM_VALID_AU=.1, HEADER_FROM_DIFFERENT_DOMAINS=249,
	MAILING_LIST_MULTI=, RCVD_IN_DNSWL_MED=.3, SPF_HELO_NONE=001,
	SPF_PASS=.001] autolearn=m autolearn_force=
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=ss (2048-bit key) header.d=ul-moore.com
Received: from a.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 6rWfpHsXJeIC for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 22:17:58 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=ilfrom; client-ip\x139.178.88.99; helo=.mirrors.kernel.org; envelope-from=nux-security-module+bounces-2441-steffen.klassert=cunet.com@vger.kernel.org; receiver=effen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com 7949C20897
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by a.mx.secunet.com (Postfix) with ESMTPS id 7949C20897
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:17:58 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sv.mirrors.kernel.org (Postfix) with ESMTPS id D6F93284999
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:17:56 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 6173B13B2B8;
	Fri, 29 Mar 2024 21:17:53 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=h3CqDiO"
X-Original-To: linux-security-module@vger.kernel.org
Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F05413792C
	for <linux-security-module@vger.kernel.org>; Fri, 29 Mar 2024 21:17:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=ne smtp.client-ip 9.85.128.173
ARC-Seal: i= a=a-sha256; d=bspace.kernel.org; s=c-20240116;
	t\x1711747073; cv=ne; b=0xxMrCvFvLIw7D410s0q3glAahyW/+EQm15kv5rP/KobURHq0XpJsVzIHhLpPhUSQAMe5xP95NbG3uA6gS4o20mk3XEe+Ax+xauQ5EXkCwaDrt/OEtSIcWdQQeJbtc07hUGIFEY59MEey0aIPa2ekWA73VosMT7YiXtHX6MVAARC-Message-Signature: i= a=a-sha256; d=bspace.kernel.org;
	s=c-20240116; t\x1711747073; c=laxed/simple;
	bh=xP9z1f9YIuDyEcTXldM/7w/7mNjSwV0ZwC3PgLpPs=
	h=ME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=+pad2noemRe/01E+nppjp0MEObj20OFHLBqEFQEGbrVDPrsnpzyZC3j6TkMX+iAI2SKfkfJZPryA9cdSbs8cT3eg17kcjOG/cgErTzcq5nIutU/92Nh3E4lr+/BIvO4oIGAREmu6M1jc+n/mYLSZOyKHVmg0y8K4fveH/xl18ARC-Authentication-Results: i= smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com; spf=ss smtp.mailfrom=ul-moore.com; dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=3CqDiO; arc=ne smtp.client-ip 9.85.128.173
Authentication-Results: smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com
Authentication-Results: smtp.subspace.kernel.org; spf=ss smtp.mailfrom=ul-moore.com
Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-61149e50602so17688927b3.0
        for <linux-security-module@vger.kernel.org>; Fri, 29 Mar 2024 14:17:51 -0700 (PDT)
DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d=ul-moore.com; s=ogle; t\x1711747070; x\x1712351870; darn=er.kernel.org;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=
        b=3CqDiO/ILBM1o5Ike9xgWVppnr/6nU6Wz4cfl8fRvc2Tgi1/fBtVRtIWYTWDMKau
         vVTbv78S4hRF6PSluag5YgKwILHMV6pCFCXWEvjHB7An/vD2npvCki/aQYeYNKkq9+vm
         XCH6qUkq+YkCcar7lh3vJW14LIVzMOqpUzEb5OJW/C79skYDsPFCVpOZgBezr9c4wYi9
         4CK0DOMNzLtislLVM9yQdSDVApHSu0jE7oN+fcC7dS9/NfOIPvZm4IEeNkRiWuwx7rb6
         7L03w0rrFbr3Kw4rj0ioArMxEEJUECm9Bv0grqR+n7AnXY79/phZXa9PEkvgNQTgpM9C
         rJYg=
X-Google-DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d\x1e100.net; s 230601; t\x1711747070; x\x1712351870;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=K0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=
        b=7gkbCbMPuVxTRRjx9JBP4VfAihO2hPCp2YXAEWnSLdbiDiZ4DTWU6L5BH7XcDUSB
         /wU+n3p5Aj/p+cQpX5QEXfTzDlmXh+oLF7kC/OHUSw2L+D1kVUoA7TYv/ofQqvilgDQm
         /IM+U3tX7wvz2mCkRpMF/8DOnhzRs/6R4RdbwmdnhEE028sOQnGFPGRHLv+j1JSRPo4+
         5fyk3JjZaV8SJ6c2JZtr27PKwVLIuxBTlDE41KlhYvxXJ5+VX+kn0AXM3cfmbGJje8JI
         51LflsTAAX2hdaXgqzPSidnVT4nviYPyQaqDYdLBN8bdF680rKvzulj7IPIpcu1LU8OS
         19MA=
X-Forwarded-Encrypted: i= AJvYcCW1iHuqoUPf8eeB4lTRfg9A+9rDZzuxqsat70M7Y8L7BtDcZdIgYuLy+9RGTx/ryj6FiQGpKCzMI05nIjQcjpdJhG5OIZH6isoZv548gSfOilUMblfw
X-Gm-Message-State: AOJu0YyCrk2d1/wzo8za3da7BrXdJ0hNdy0nji6DM1yDcbRysdDzVVc6
	xJv8eOMJ6jTZ7UBEroyfLUYyL47RnAK4xXX2WrY89pXneGxcq01Sz1w5BICx1w8zubHrziIdwkV
	jyuOikvzrduDLkAiUHxfxmX3A0TmD8gSjvxWy
X-Google-Smtp-Source: AGHT+IGFGTkGUMvueIT/Rbb7ioKXQmsJLC9q2uWVMLN0FJu8IukA0N8cMfmV+QovgZ4y/9qL51xfw0+ynHKqeUiSvEgX-Received: by 2002:a05:690c:dd0:b0:614:5b8c:9b9 with SMTP id
 db16-20020a05690c0dd000b006145b8c09b9mr1542912ywb.9.1711747070429; Fri, 29
 Mar 2024 14:17:50 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-security-module@vger.kernel.org
List-Id: <linux-security-module.vger.kernel.org>
List-Subscribe: <mailto:linux-security-module+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-security-module+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20240327120036.233641-1-mic@digikod.net> <bd62ac88-81bc-cee2-639a-a0ca79843265@huawei-partners.com>
 <CAHC9VhRN4deUerWtxxGypFH1o+NRD=U96H2qB0xv+0d6ekEA@mail.gmail.com>
In-Reply-To: <CAHC9VhRN4deUerWtxxGypFH1o+NRD=U96H2qB0xv+0d6ekEA@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 29 Mar 2024 17:17:39 -0400
Message-ID: <CAHC9VhSbOLR+yFbC6081UL87L2-SNV+gOBi2tD1YE7Th5hsGCw@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect
To: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Cc: =TF-8?B?TWlja2HDq2wgU2FsYcO8bg==ic@digikod.net>, 
	linux-security-module@vger.kernel.org, netdev@vger.kernel.org, 
	Eric Dumazet <edumazet@google.com>, =TF-8?Q?Günther_Noack?=noack@google.com>, 
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>, 
	Muhammad Usama Anjum <usama.anjum@collabora.com>, "Serge E . Hallyn" <serge@hallyn.com>, 
	yusongping <yusongping@huawei.com>, artem.kuzin@huawei.com
Content-Type: text/plain; charset=TF-8"
Content-Transfer-Encoding: quoted-printable
Return-Path: linux-security-module+bounces-2441-steffen.klassert=cunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 21:18:02.5569
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: da0fa88a-324e-4f61-834d-08dc5035b7b8
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=x-dresden-01.secunet.de:TOTAL-HUB=442|SMR=358(SMRDE=034|SMRC=323(SMRCL=101|X-SMRCR=323))|CAT=083(CATOS=012
 (CATSM=012(CATSM-Malware
 Agent=012))|CATRESL=039(CATRESLP2R=021)|CATORES=027
 (CATRS=027(CATRS-Index Routing
 Agent=026))|CATORT=002(CATRT=002(CATRT-Journal Agent=001
 )));2024-03-29T21:18:03.005Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 10697
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRVÊs-essen-01.secunet.de:TOTAL-FE=008|SMR=008(SMRPI=006(SMRPI-FrontendProxyAgent=006))
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAdkFAAAPAAADH4sIAAAAAAAEAHVVy24bNxSlrLdk2S3STX
 cX6SJJYSu2EyCtEbhp0QdUxGiAdFcUBjVDeViNSJXkSNGuv9Dv6KI/
 0F3+pF/Sc8mRrCYIMBpwSN7Dc8+5l/rz+CdD3zt9QtfS0cWXJ3Rxdv
 GUZKCnl2fP/v3j71fX9EpWJV1b6xQ9X2L8gl+nC54YZ3ZxRWtng7oc
 Da7wEPB+Lqoa74s7vPPzy/NzAH59TZOVNHZF13peSF1y0HMdp8aLNH
 X+oqjkWunTpXTBKOffOYfiMU8eXzx7HOGfXJ6d0atrHKqzuXz7V0mv
 ZSnf/mP+F3JF36hMVl5RKBR5lVVOh82Nt9lchZupNjlJ/D64WFg79y
 Sd2sJlsixVTlM1Y204zqiwtm5OPshsfkI6kPakpN9QsKRNcDavMkXK
 Oesos/kOSpvMGq99UCbTyo9pYjCWOdkZyTzX5hbYa8oKlYEDwMDPKR
 Mi41kVqjtWL19f+xMqVXjgaabfRF5OlTKolALOitBj+KT2UZEZydJh
 abPFesgGaKS5eUR6sSzVAmdyyht6/d1Lbao3kcBLvErLGfMXsvaFrc
 qcjA07rQppbhVBfUd+KSHCVBVypaHDtAoM7uxqXxm6E2SzoxzREuQk
 0DoegsCpnJYbAOIJAQdAH3C26/c94aWlcjBsQb7KioRVC1Abybay4B
 Ayec5KwceF3EBWeAKMmWV83lUzZ2H8tgfG43E9uroLdcpXJTI1+4Yu
 VChsREyVdnpll34bPKHcmgcBWWgz51xADmCS7t/h3SeejqW21mVJnz
 v1e6Wd+hzbcADDJOTLS/AM9gb4KBiTBW0NPQQVd7OSpc5RH189GhNN
 ZrSxFa0liovFqpyvYm0FTmStQ7FVNVcr1iHVo1fgNuOlTe0L7GBGnC
 n7kdtlLAZWHWVCcgk+EuPJLj8Z7kIl3aISIVeuJFj9WPkQEaUzKj9J
 fFgP1BDbrgzlejbTGSRB/7DKzHIpEbYusBrcpmZyq7hrNpDFRULoMH
 ZaZrhjFhY6QBhI5OzivURhzGjwy7fOLpcMJkv1Rm3GcwQZtXphnczK
 eCVSXik+Si1wmaWa9vSwMnNj1wbGZXqpUS+PfmW8yYMFlSiziBgSbe
 u9nuoSNxDTy22kjgU55SZJtxTcwONRhiX6Fafypmld4wvsir6sC/iR
 ZOJSQvtpW3l0S3BabWGiWKMBq8UVwDcHWpcRfOx6Hm27whqFLlipEr
 SQDC41mEu72hoNdsUV0JWozJjQ+6UXV2u/AztklIqN8Fu1WI4Ge+Co
 FY8a1vEGi0jvoIDzD07Giwmp4hpDpqNBkGXUFO2O/xFuAYJ4rkAHn8
 Q7Z4KcTCzcqALfRmwBtJO+cgw8GiB9mSHQ8HVkVDzUP8bfgzVcpiYr
 FtKhA9aFRimXeq4grfYs9a2tC24KHAlmJTxS9UUYK+n0lDXf/y/lWS
 EORLMp2s2GOMQjWgei1RLtg0azK0RX9DBui26rIe6Jdhx3mvwefSiq
 J0RP9Dui2xWHnYb4THTTJ94x8BCBjYbo4xEHGLca7XhQH2dhW1scYd
 AUrV5DfBIDAYvPd2YijSHGeLCEEJAEGgOChmj2xQB7WuLwWHyMVcyk
 nZ24LR3REUct0YlQrQSC2C7zbKWdcfKjvhgOI+2amBg0Od8EONzxiQ
 kmJji3jZCuuIdtaSntT5+7bQmzJQYpkYTf3qa8S+RQUJpJCPuJdDhk
 2BAH7ZhIwmywNdgA5E4UpNNlvQ+afEqvzcp3UiKwdSTavdrN+sQO5q
 PX6ZSEmVJOmSbaMZd+CulF/JT4lkP67G4xh2kVz+HecXhSIknzVoTF
 4Egc7xEYcgk1xKdRopR+4gNMZITJvjhOqqbw5FeSOr23NHqdLaXdk6
 AiSKqZdqrt1taInXdbg+pEOMdaTGjYb0die/L2kyNpczJiNx5EQeKe
 3rY+eQDhBjHrVGbRtaQMC4XPAdoqkhnGQcJJNiXlD2JUFOoYo6PULP
 8Btex2bXoLAAABCskDPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu
 Zz0idXRmLTE2Ij8+DQo8RW1haWxTZXQ+DQogIDxWZXJzaW9uPjE1Lj
 AuMC4wPC9WZXJzaW9uPg0KICA8RW1haWxzPg0KICAgIDxFbWFpbCBT
 dGFydEluZGV4PSI0NCIgUG9zaXRpb249IlNpZ25hdHVyZSI+DQogIC
 AgICA8RW1haWxTdHJpbmc+cGF1bEBwYXVsLW1vb3JlLmNvbTwvRW1h
 aWxTdHJpbmc+DQogICAgPC9FbWFpbD4NCiAgICA8RW1haWwgU3Rhcn
 RJbmRleD0iMTMwIj4NCiAgICAgIDxFbWFpbFN0cmluZz5pdmFub3Yu
 bWlraGFpbDFAaHVhd2VpLXBhcnRuZXJzLmNvbTwvRW1haWxTdHJpbm
 c+DQogICAgPC9FbWFpbD4NCiAgICA8RW1haWwgU3RhcnRJbmRleD0i
 MTMzMyI+DQogICAgICA8RW1haWxTdHJpbmc+YWxleGV5LmtvZGFuZX
 ZAb3JhY2xlLmNvbTwvRW1haWxTdHJpbmc+DQogICAgPC9FbWFpbD4N
 CiAgPC9FbWFpbHM+DQo8L0VtYWlsU2V0PgEL0QE8P3htbCB2ZXJzaW
 9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxVcmxTZXQ+DQog
 IDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VXJscz4NCi
 AgICA8VXJsIFN0YXJ0SW5kZXg9IjE5MTMiIFR5cGU9IlVybCI+DQog
 ICAgICA8VXJsU3RyaW5nPnBhdWwtbW9vcmUuY29tPC9VcmxTdHJpbm
 c+DQogICAgPC9Vcmw+DQogIDwvVXJscz4NCjwvVXJsU2V0PgEMwAc8
 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCj
 xDb250YWN0U2V0Pg0KICA8VmVyc2lvbj4xNS4wLjAuMDwvVmVyc2lv
 bj4NCiAgPENvbnRhY3RzPg0KICAgIDxDb250YWN0IFN0YXJ0SW5kZX
 g9IjMyIiBQb3NpdGlvbj0iU2lnbmF0dXJlIj4NCiAgICAgIDxQZXJz
 b24gU3RhcnRJbmRleD0iMzIiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg
 0KICAgICAgICA8UGVyc29uU3RyaW5nPlBhdWwgTW9vcmU8L1BlcnNv
 blN0cmluZz4NCiAgICAgIDwvUGVyc29uPg0KICAgICAgPEVtYWlscz
 4NCiAgICAgICAgPEVtYWlsIFN0YXJ0SW5kZXg9IjQ0IiBQb3NpdGlv
 bj0iU2lnbmF0dXJlIj4NCiAgICAgICAgICA8RW1haWxTdHJpbmc+cG
 F1bEBwYXVsLW1vb3JlLmNvbTwvRW1haWxTdHJpbmc+DQogICAgICAg
 IDwvRW1haWw+DQogICAgICA8L0VtYWlscz4NCiAgICAgIDxDb250YW
 N0U3RyaW5nPlBhdWwgTW9vcmUgJmx0O3BhdWxAcGF1bC1tb29yZS5j
 b208L0NvbnRhY3RTdHJpbmc+DQogICAgPC9Db250YWN0Pg0KICAgID
 xDb250YWN0IFN0YXJ0SW5kZXg9IjExMSI+DQogICAgICA8UGVyc29u
 IFN0YXJ0SW5kZXg9IjExMSI+DQogICAgICAgIDxQZXJzb25TdHJpbm
 c+SXZhbm92IE1pa2hhaWw8L1BlcnNvblN0cmluZz4NCiAgICAgIDwv
 UGVyc29uPg0KICAgICAgPEVtYWlscz4NCiAgICAgICAgPEVtYWlsIF
 N0YXJ0SW5kZXg9IjEzMCI+DQogICAgICAgICAgPEVtYWlsU3RyaW5n
 Pml2YW5vdi5taWtoYWlsMUBodWF3ZWktcGFydG5lcnMuY29tPC9FbW
 FpbFN0cmluZz4NCiAgICAgICAgPC9FbWFpbD4NCiAgICAgIDwvRW1h
 aWxzPg0KICAgICAgPENvbnRhY3RTdHJpbmc+SXZhbm92IE1pa2hhaW
 wNCiZndDsgJmx0O2l2YW5vdi5taWtoYWlsMUBodWF3ZWktcGFydG5l
 cnMuY29tPC9Db250YWN0U3RyaW5nPg0KICAgIDwvQ29udGFjdD4NCi
 AgPC9Db250YWN0cz4NCjwvQ29udGFjdFNldD4BDs8BUmV0cmlldmVy
 T3BlcmF0b3IsMTAsMDtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3
 REb2NQYXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVy
 YXRvciwxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYX
 RvciwxMCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRv
 ciwxMSwwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE1
X-MS-Exchange-Forest-IndexAgent: 1 3357
X-MS-Exchange-Forest-EmailMessageHash: 7C7AEC4C
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

X-sender: <netdev+bounces-83463-steffen.klassert=cunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=c822;steffen.klassert@secunet.com NOTIFY=VER; X-ExtendedProps=AVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ=
X-CreatedBy: MSExchange15
X-HeloDomain: a.mx.secunet.com
X-ExtendedProps: BQBjAAoAi5Hp8x1Q3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAGIACgBRAAAAi4oAAAUABAAUIAEAAAAcAAAAc3RlZmZlbi5rbGFzc2VydEBzZWN1bmV0LmNvbQUABgACAAEFACkAAgABDwAJAAAAQ0lBdWRpdGVkAgABBQACAAcAAQAAAAUAAwAHAAAAAAAFAAUAAgABBQBkAA8AAwAAAEh1Yg=
X-Source: SMTP:Default MBX-DRESDEN-01
X-SourceIPAddress: 62.96.220.36
X-EndOfInjectedXHeaders: 16836
Received: from cas-essen-01.secunet.de (10.53.40.201) by
 mbx-dresden-01.secunet.de (10.53.40.199) with Microsoft SMTP Server
 (version=S1_2, cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 22:18:06 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=S1_2,
 cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 22:18:06 +0100
Received: from localhost (localhost [127.0.0.1])
	by a.mx.secunet.com (Postfix) with ESMTP id ED14E208A3
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:18:06 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=.751 tagged_above=99 required=1
	tests=AYES_00=.9, DKIM_SIGNED=1, DKIM_VALID=.1,
	DKIM_VALID_AU=.1, HEADER_FROM_DIFFERENT_DOMAINS=249,
	MAILING_LIST_MULTI=, RCVD_IN_DNSWL_NONE=.0001,
	SPF_HELO_NONE=001, SPF_PASS=.001]
	autolearn=available autolearn_force=
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=ss (2048-bit key) header.d=ul-moore.com
Received: from a.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oDDZ24243v52 for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 22:18:03 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=ilfrom; client-ip\x147.75.48.161; helo=.mirrors.kernel.org; envelope-from=tdev+bounces-83463-steffen.klassert=cunet.com@vger.kernel.org; receiver=effen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com C717420897
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by a.mx.secunet.com (Postfix) with ESMTPS id C717420897
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:18:02 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sy.mirrors.kernel.org (Postfix) with ESMTPS id CA490B2280D
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:17:59 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id B59A813BAEF;
	Fri, 29 Mar 2024 21:17:53 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=h3CqDiO"
X-Original-To: netdev@vger.kernel.org
Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7ABE238FAD
	for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 21:17:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=ne smtp.client-ip 9.85.128.171
ARC-Seal: i= a=a-sha256; d=bspace.kernel.org; s=c-20240116;
	t\x1711747073; cv=ne; b=FpzL+j6s4ROoZ9m+WmRtsDbZPWvRPaAOlVul1gnl+922OJOoBjb/HuCJ3iwPEDK1mF78WeWA2yuFgsFHBrCRseNrUIdkld7b6M1n5XUBTydlOahTDDwsLfuL7ySFyoJqk9bIJUeJ23RDhu4gE9DfMFDCA3hZRkhoyIXuxxLsQARC-Message-Signature: i= a=a-sha256; d=bspace.kernel.org;
	s=c-20240116; t\x1711747073; c=laxed/simple;
	bh=xP9z1f9YIuDyEcTXldM/7w/7mNjSwV0ZwC3PgLpPs=
	h=ME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=+pad2noemRe/01E+nppjp0MEObj20OFHLBqEFQEGbrVDPrsnpzyZC3j6TkMX+iAI2SKfkfJZPryA9cdSbs8cT3eg17kcjOG/cgErTzcq5nIutU/92Nh3E4lr+/BIvO4oIGAREmu6M1jc+n/mYLSZOyKHVmg0y8K4fveH/xl18ARC-Authentication-Results: i= smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com; spf=ss smtp.mailfrom=ul-moore.com; dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=3CqDiO; arc=ne smtp.client-ip 9.85.128.171
Authentication-Results: smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com
Authentication-Results: smtp.subspace.kernel.org; spf=ss smtp.mailfrom=ul-moore.com
Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-611639a0e4eso21177477b3.0
        for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 14:17:51 -0700 (PDT)
DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d=ul-moore.com; s=ogle; t\x1711747070; x\x1712351870; darn=er.kernel.org;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=K0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=
        b=3CqDiO/ILBM1o5Ike9xgWVppnr/6nU6Wz4cfl8fRvc2Tgi1/fBtVRtIWYTWDMKau
         vVTbv78S4hRF6PSluag5YgKwILHMV6pCFCXWEvjHB7An/vD2npvCki/aQYeYNKkq9+vm
         XCH6qUkq+YkCcar7lh3vJW14LIVzMOqpUzEb5OJW/C79skYDsPFCVpOZgBezr9c4wYi9
         4CK0DOMNzLtislLVM9yQdSDVApHSu0jE7oN+fcC7dS9/NfOIPvZm4IEeNkRiWuwx7rb6
         7L03w0rrFbr3Kw4rj0ioArMxEEJUECm9Bv0grqR+n7AnXY79/phZXa9PEkvgNQTgpM9C
         rJYg=
X-Google-DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d\x1e100.net; s 230601; t\x1711747070; x\x1712351870;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=K0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=
        bçcVRi3/WlH6zhm2UHjhxjMNGMzCdBw0kiRNGZrD3F9Sy2FYI6dT0JzxAm6Q8e6/Y4
         N3+Uhs00X1PHInoevWtoON7kMo8YWAkAs4VfYnTFSThnVc4wethbrw0HVWBw0e/Ww8oP
         2EHTf37tsviNgSPAsg1JCId8d2geyyarVnyRYeZCsBQTTglBD/mlMiy2m2I4yB/sB6H1
         bYnryK66excoEb9oSigbbsNp5+vkXgQw7SzIZXX1nq1+dSgmDcEhlO/DuoioUPXVaBc0
         LXX7/KWDbTf9Q3O0NH+g7IOBDp/X/SNjkr3lY+cQM6yuiJnb9QzodPZNl8FR24dTed+C
         yheg=
X-Forwarded-Encrypted: i= AJvYcCUERtuOlGCNh+VMXzI33ZvBPsWzR2U2kdDvLuwNR7FnXsCvMA6GzCyTrDZsc8eU//coZbvHPe7F+R6hGzULlGg4z+TFtqPj
X-Gm-Message-State: AOJu0YzcaDsBlcNbpASJA/SjYACTyIQrziKr/0R/QADNO9vmVTVlTSYN
	fBH5u2AgnCCd3ByQxdGLKpOww36/eR1eh479SZIeXMFtTJ1As+WzAcJV4BnOch2p+YzXPFxySgk
	ocDfstnl3/uh1PiAfXlkT8RCWbKlGKStG4TJy
X-Google-Smtp-Source: AGHT+IGFGTkGUMvueIT/Rbb7ioKXQmsJLC9q2uWVMLN0FJu8IukA0N8cMfmV+QovgZ4y/9qL51xfw0+ynHKqeUiSvEgX-Received: by 2002:a05:690c:dd0:b0:614:5b8c:9b9 with SMTP id
 db16-20020a05690c0dd000b006145b8c09b9mr1542912ywb.9.1711747070429; Fri, 29
 Mar 2024 14:17:50 -0700 (PDT)
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20240327120036.233641-1-mic@digikod.net> <bd62ac88-81bc-cee2-639a-a0ca79843265@huawei-partners.com>
 <CAHC9VhRN4deUerWtxxGypFH1o+NRD=U96H2qB0xv+0d6ekEA@mail.gmail.com>
In-Reply-To: <CAHC9VhRN4deUerWtxxGypFH1o+NRD=U96H2qB0xv+0d6ekEA@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 29 Mar 2024 17:17:39 -0400
Message-ID: <CAHC9VhSbOLR+yFbC6081UL87L2-SNV+gOBi2tD1YE7Th5hsGCw@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect
To: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Cc: =TF-8?B?TWlja2HDq2wgU2FsYcO8bg==ic@digikod.net>, 
	linux-security-module@vger.kernel.org, netdev@vger.kernel.org, 
	Eric Dumazet <edumazet@google.com>, =TF-8?Q?Günther_Noack?=noack@google.com>, 
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>, 
	Muhammad Usama Anjum <usama.anjum@collabora.com>, "Serge E . Hallyn" <serge@hallyn.com>, 
	yusongping <yusongping@huawei.com>, artem.kuzin@huawei.com
Content-Type: text/plain; charset=TF-8"
Content-Transfer-Encoding: quoted-printable
Return-Path: netdev+bounces-83463-steffen.klassert=cunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 21:18:06.9907
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: bb0b4948-f2f7-4c56-35b5-08dc5035ba5d
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=x-dresden-01.secunet.de:TOTAL-HUB=412|SMR=344(SMRDE=034|SMRC=309(SMRCL=101|X-SMRCR=310))|CAT=067(CATOS=015
 (CATSM=014(CATSM-Malware
 Agent=014))|CATRESL=020(CATRESLP2R=017)|CATORES=030
 (CATRS=030(CATRS-Index Routing Agent=029)));2024-03-29T21:18:07.405Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-dresden-01.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 10555
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRVÊs-essen-01.secunet.de:TOTAL-FE=005|SMR=005(SMRPI=003(SMRPI-FrontendProxyAgent=003))
X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Organization-RulesExecuted: mbx-dresden-01
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAdkFAAAPAAADH4sIAAAAAAAEAHVVy24bNxSlrLdk2S3STX
 cX6SJJYSu2EyCtEbhp0QdUxGiAdFcUBjVDeViNSJXkSNGuv9Dv6KI/
 0F3+pF/Sc8mRrCYIMBpwSN7Dc8+5l/rz+CdD3zt9QtfS0cWXJ3Rxdv
 GUZKCnl2fP/v3j71fX9EpWJV1b6xQ9X2L8gl+nC54YZ3ZxRWtng7oc
 Da7wEPB+Lqoa74s7vPPzy/NzAH59TZOVNHZF13peSF1y0HMdp8aLNH
 X+oqjkWunTpXTBKOffOYfiMU8eXzx7HOGfXJ6d0atrHKqzuXz7V0mv
 ZSnf/mP+F3JF36hMVl5RKBR5lVVOh82Nt9lchZupNjlJ/D64WFg79y
 Sd2sJlsixVTlM1Y204zqiwtm5OPshsfkI6kPakpN9QsKRNcDavMkXK
 Oesos/kOSpvMGq99UCbTyo9pYjCWOdkZyTzX5hbYa8oKlYEDwMDPKR
 Mi41kVqjtWL19f+xMqVXjgaabfRF5OlTKolALOitBj+KT2UZEZydJh
 abPFesgGaKS5eUR6sSzVAmdyyht6/d1Lbao3kcBLvErLGfMXsvaFrc
 qcjA07rQppbhVBfUd+KSHCVBVypaHDtAoM7uxqXxm6E2SzoxzREuQk
 0DoegsCpnJYbAOIJAQdAH3C26/c94aWlcjBsQb7KioRVC1Abybay4B
 Ayec5KwceF3EBWeAKMmWV83lUzZ2H8tgfG43E9uroLdcpXJTI1+4Yu
 VChsREyVdnpll34bPKHcmgcBWWgz51xADmCS7t/h3SeejqW21mVJnz
 v1e6Wd+hzbcADDJOTLS/AM9gb4KBiTBW0NPQQVd7OSpc5RH189GhNN
 ZrSxFa0liovFqpyvYm0FTmStQ7FVNVcr1iHVo1fgNuOlTe0L7GBGnC
 n7kdtlLAZWHWVCcgk+EuPJLj8Z7kIl3aISIVeuJFj9WPkQEaUzKj9J
 fFgP1BDbrgzlejbTGSRB/7DKzHIpEbYusBrcpmZyq7hrNpDFRULoMH
 ZaZrhjFhY6QBhI5OzivURhzGjwy7fOLpcMJkv1Rm3GcwQZtXphnczK
 eCVSXik+Si1wmaWa9vSwMnNj1wbGZXqpUS+PfmW8yYMFlSiziBgSbe
 u9nuoSNxDTy22kjgU55SZJtxTcwONRhiX6Fafypmld4wvsir6sC/iR
 ZOJSQvtpW3l0S3BabWGiWKMBq8UVwDcHWpcRfOx6Hm27whqFLlipEr
 SQDC41mEu72hoNdsUV0JWozJjQ+6UXV2u/AztklIqN8Fu1WI4Ge+Co
 FY8a1vEGi0jvoIDzD07Giwmp4hpDpqNBkGXUFO2O/xFuAYJ4rkAHn8
 Q7Z4KcTCzcqALfRmwBtJO+cgw8GiB9mSHQ8HVkVDzUP8bfgzVcpiYr
 FtKhA9aFRimXeq4grfYs9a2tC24KHAlmJTxS9UUYK+n0lDXf/y/lWS
 EORLMp2s2GOMQjWgei1RLtg0azK0RX9DBui26rIe6Jdhx3mvwefSiq
 J0RP9Dui2xWHnYb4THTTJ94x8BCBjYbo4xEHGLca7XhQH2dhW1scYd
 AUrV5DfBIDAYvPd2YijSHGeLCEEJAEGgOChmj2xQB7WuLwWHyMVcyk
 nZ24LR3REUct0YlQrQSC2C7zbKWdcfKjvhgOI+2amBg0Od8EONzxiQ
 kmJji3jZCuuIdtaSntT5+7bQmzJQYpkYTf3qa8S+RQUJpJCPuJdDhk
 2BAH7ZhIwmywNdgA5E4UpNNlvQ+afEqvzcp3UiKwdSTavdrN+sQO5q
 PX6ZSEmVJOmSbaMZd+CulF/JT4lkP67G4xh2kVz+HecXhSIknzVoTF
 4Egc7xEYcgk1xKdRopR+4gNMZITJvjhOqqbw5FeSOr23NHqdLaXdk6
 AiSKqZdqrt1taInXdbg+pEOMdaTGjYb0die/L2kyNpczJiNx5EQeKe
 3rY+eQDhBjHrVGbRtaQMC4XPAdoqkhnGQcJJNiXlD2JUFOoYo6PULP
 8Btex2bXoLAAABCskDPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu
 Zz0idXRmLTE2Ij8+DQo8RW1haWxTZXQ+DQogIDxWZXJzaW9uPjE1Lj
 AuMC4wPC9WZXJzaW9uPg0KICA8RW1haWxzPg0KICAgIDxFbWFpbCBT
 dGFydEluZGV4PSI0NCIgUG9zaXRpb249IlNpZ25hdHVyZSI+DQogIC
 AgICA8RW1haWxTdHJpbmc+cGF1bEBwYXVsLW1vb3JlLmNvbTwvRW1h
 aWxTdHJpbmc+DQogICAgPC9FbWFpbD4NCiAgICA8RW1haWwgU3Rhcn
 RJbmRleD0iMTMwIj4NCiAgICAgIDxFbWFpbFN0cmluZz5pdmFub3Yu
 bWlraGFpbDFAaHVhd2VpLXBhcnRuZXJzLmNvbTwvRW1haWxTdHJpbm
 c+DQogICAgPC9FbWFpbD4NCiAgICA8RW1haWwgU3RhcnRJbmRleD0i
 MTMzMyI+DQogICAgICA8RW1haWxTdHJpbmc+YWxleGV5LmtvZGFuZX
 ZAb3JhY2xlLmNvbTwvRW1haWxTdHJpbmc+DQogICAgPC9FbWFpbD4N
 CiAgPC9FbWFpbHM+DQo8L0VtYWlsU2V0PgEL0QE8P3htbCB2ZXJzaW
 9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCjxVcmxTZXQ+DQog
 IDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW9uPg0KICA8VXJscz4NCi
 AgICA8VXJsIFN0YXJ0SW5kZXg9IjE5MTMiIFR5cGU9IlVybCI+DQog
 ICAgICA8VXJsU3RyaW5nPnBhdWwtbW9vcmUuY29tPC9VcmxTdHJpbm
 c+DQogICAgPC9Vcmw+DQogIDwvVXJscz4NCjwvVXJsU2V0PgEMwAc8
 P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJ1dGYtMTYiPz4NCj
 xDb250YWN0U2V0Pg0KICA8VmVyc2lvbj4xNS4wLjAuMDwvVmVyc2lv
 bj4NCiAgPENvbnRhY3RzPg0KICAgIDxDb250YWN0IFN0YXJ0SW5kZX
 g9IjMyIiBQb3NpdGlvbj0iU2lnbmF0dXJlIj4NCiAgICAgIDxQZXJz
 b24gU3RhcnRJbmRleD0iMzIiIFBvc2l0aW9uPSJTaWduYXR1cmUiPg
 0KICAgICAgICA8UGVyc29uU3RyaW5nPlBhdWwgTW9vcmU8L1BlcnNv
 blN0cmluZz4NCiAgICAgIDwvUGVyc29uPg0KICAgICAgPEVtYWlscz
 4NCiAgICAgICAgPEVtYWlsIFN0YXJ0SW5kZXg9IjQ0IiBQb3NpdGlv
 bj0iU2lnbmF0dXJlIj4NCiAgICAgICAgICA8RW1haWxTdHJpbmc+cG
 F1bEBwYXVsLW1vb3JlLmNvbTwvRW1haWxTdHJpbmc+DQogICAgICAg
 IDwvRW1haWw+DQogICAgICA8L0VtYWlscz4NCiAgICAgIDxDb250YW
 N0U3RyaW5nPlBhdWwgTW9vcmUgJmx0O3BhdWxAcGF1bC1tb29yZS5j
 b208L0NvbnRhY3RTdHJpbmc+DQogICAgPC9Db250YWN0Pg0KICAgID
 xDb250YWN0IFN0YXJ0SW5kZXg9IjExMSI+DQogICAgICA8UGVyc29u
 IFN0YXJ0SW5kZXg9IjExMSI+DQogICAgICAgIDxQZXJzb25TdHJpbm
 c+SXZhbm92IE1pa2hhaWw8L1BlcnNvblN0cmluZz4NCiAgICAgIDwv
 UGVyc29uPg0KICAgICAgPEVtYWlscz4NCiAgICAgICAgPEVtYWlsIF
 N0YXJ0SW5kZXg9IjEzMCI+DQogICAgICAgICAgPEVtYWlsU3RyaW5n
 Pml2YW5vdi5taWtoYWlsMUBodWF3ZWktcGFydG5lcnMuY29tPC9FbW
 FpbFN0cmluZz4NCiAgICAgICAgPC9FbWFpbD4NCiAgICAgIDwvRW1h
 aWxzPg0KICAgICAgPENvbnRhY3RTdHJpbmc+SXZhbm92IE1pa2hhaW
 wNCiZndDsgJmx0O2l2YW5vdi5taWtoYWlsMUBodWF3ZWktcGFydG5l
 cnMuY29tPC9Db250YWN0U3RyaW5nPg0KICAgIDwvQ29udGFjdD4NCi
 AgPC9Db250YWN0cz4NCjwvQ29udGFjdFNldD4BDs8BUmV0cmlldmVy
 T3BlcmF0b3IsMTAsMTtSZXRyaWV2ZXJPcGVyYXRvciwxMSwxO1Bvc3
 REb2NQYXJzZXJPcGVyYXRvciwxMCwwO1Bvc3REb2NQYXJzZXJPcGVy
 YXRvciwxMSwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYX
 RvciwxMCwwO1Bvc3RXb3JkQnJlYWtlckRpYWdub3N0aWNPcGVyYXRv
 ciwxMSwwO1RyYW5zcG9ydFdyaXRlclByb2R1Y2VyLDIwLDE4
X-MS-Exchange-Forest-IndexAgent: 1 3357
X-MS-Exchange-Forest-EmailMessageHash: 7C7AEC4C
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 13552 bytes --]

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

X-sender: <netdev+bounces-83463-steffen.klassert=secunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=rfc822;steffen.klassert@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-dresden-01.secunet.de
X-ExtendedProps: BQBjAAoARUemlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.199
X-EndOfInjectedXHeaders: 11104
Received: from mbx-dresden-01.secunet.de (10.53.40.199) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 22:18:07 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 22:18:06 +0100
Received: from localhost (localhost [127.0.0.1])
	by a.mx.secunet.com (Postfix) with ESMTP id ED14E208A3
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:18:06 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=2.1
	tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
	DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
	MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001,
	SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
	autolearn=unavailable autolearn_force=no
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=pass (2048-bit key) header.d=paul-moore.com
Received: from a.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id oDDZ24243v52 for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 22:18:03 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip\x147.75.48.161; helo=sy.mirrors.kernel.org; envelope-from=netdev+bounces-83463-steffen.klassert=secunet.com@vger.kernel.org; receiver=steffen.klassert@secunet.com
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com C717420897
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by a.mx.secunet.com (Postfix) with ESMTPS id C717420897
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:18:02 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sy.mirrors.kernel.org (Postfix) with ESMTPS id CA490B2280D
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:17:59 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id B59A813BAEF;
	Fri, 29 Mar 2024 21:17:53 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b="eh3CqDiO"
X-Original-To: netdev@vger.kernel.org
Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7ABE238FAD
	for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 21:17:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip 9.85.128.171
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t\x1711747073; cv=none; b=IEFpzL+j6s4ROoZ9m+WmRtsDbZPWvRPaAOlVul1gnl+922OJOoBjb/HuCJ3iwPEDK1mF78WeWA2yuFgsFHBrCRseNrUIdkld7b6M1n5XUBTydlOahTDDwsLfuL7ySFyoJqk9bIJUeJ23RDhu4gE9DfMFDCA3hZRkhoyIXuxxLsQARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t\x1711747073; c=relaxed/simple;
	bh=qXxP9z1f9YIuDyEcTXldM/7w/7mNjSwV0ZwC3PgLpPs=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=iZ+pad2noemRe/01E+nppjp0MEObj20OFHLBqEFQEGbrVDPrsnpzyZC3j6TkMX+iAI2SKfkfJZPryA9cdSbs8cT3eg17kcjOG/cgErTzcq5nIutU/92Nh3E4lr+/BIvO4oIGAREmu6M1jc+n/mYLSZOyKHVmg0y8K4fveH/xl18ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com; spf=pass smtp.mailfrom=paul-moore.com; dkim=pass (2048-bit key) header.d=paul-moore.com header.i=@paul-moore.com header.b=eh3CqDiO; arc=none smtp.client-ip 9.85.128.171
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=paul-moore.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=paul-moore.com
Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-611639a0e4eso21177477b3.0
        for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 14:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=paul-moore.com; s=google; t\x1711747070; x\x1712351870; darn=vger.kernel.org;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=5SK0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=;
        b=eh3CqDiO/ILBM1o5Ike9xgWVppnr/6nU6Wz4cfl8fRvc2Tgi1/fBtVRtIWYTWDMKau
         vVTbv78S4hRF6PSluag5YgKwILHMV6pCFCXWEvjHB7An/vD2npvCki/aQYeYNKkq9+vm
         XCH6qUkq+YkCcar7lh3vJW14LIVzMOqpUzEb5OJW/C79skYDsPFCVpOZgBezr9c4wYi9
         4CK0DOMNzLtislLVM9yQdSDVApHSu0jE7oN+fcC7dS9/NfOIPvZm4IEeNkRiWuwx7rb6
         7L03w0rrFbr3Kw4rj0ioArMxEEJUECm9Bv0grqR+n7AnXY79/phZXa9PEkvgNQTgpM9C
         rJYg=X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d\x1e100.net; s 230601; t\x1711747070; x\x1712351870;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=5SK0aBd2Tg31RqeqE4efItlHudPBAE0xGZkol4kgIAk=;
        bçcVRi3/WlH6zhm2UHjhxjMNGMzCdBw0kiRNGZrD3F9Sy2FYI6dT0JzxAm6Q8e6/Y4
         N3+Uhs00X1PHInoevWtoON7kMo8YWAkAs4VfYnTFSThnVc4wethbrw0HVWBw0e/Ww8oP
         2EHTf37tsviNgSPAsg1JCId8d2geyyarVnyRYeZCsBQTTglBD/mlMiy2m2I4yB/sB6H1
         bYnryK66excoEb9oSigbbsNp5+vkXgQw7SzIZXX1nq1+dSgmDcEhlO/DuoioUPXVaBc0
         LXX7/KWDbTf9Q3O0NH+g7IOBDp/X/SNjkr3lY+cQM6yuiJnb9QzodPZNl8FR24dTed+C
         yheg=X-Forwarded-Encrypted: i=1; AJvYcCUERtuOlGCNh+VMXzI33ZvBPsWzR2U2kdDvLuwNR7FnXsCvMA6GzCyTrDZsc8eU//coZbvHPe7F+R6hGzULlGg4z+TFtqPj
X-Gm-Message-State: AOJu0YzcaDsBlcNbpASJA/SjYACTyIQrziKr/0R/QADNO9vmVTVlTSYN
	fBH5u2AgnCCd3ByQxdGLKpOww36/eR1eh479SZIeXMFtTJ1As+WzAcJV4BnOch2p+YzXPFxySgk
	ocDfstnl3/uh1PiAfXlkT8RCWbKlGKStG4TJy
X-Google-Smtp-Source: AGHT+IGFGTkGUMvueIT/Rbb7ioKXQmsJLC9q2uWVMLN0FJu8IukA0N8cMfmV+QovgZ4y/9qL51xfw0+ynHKqeUiSvEgX-Received: by 2002:a05:690c:dd0:b0:614:5b8c:9b9 with SMTP id
 db16-20020a05690c0dd000b006145b8c09b9mr1542912ywb.9.1711747070429; Fri, 29
 Mar 2024 14:17:50 -0700 (PDT)
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20240327120036.233641-1-mic@digikod.net> <bd62ac88-81bc-cee2-639a-a0ca79843265@huawei-partners.com>
 <CAHC9VhRN4deUerWtxxGypFH1o+NRD=Z+U96H2qB0xv+0d6ekEA@mail.gmail.com>
In-Reply-To: <CAHC9VhRN4deUerWtxxGypFH1o+NRD=Z+U96H2qB0xv+0d6ekEA@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 29 Mar 2024 17:17:39 -0400
Message-ID: <CAHC9VhSbOLR+yFbC6081UL87L2-SNV+gOBi2tD1YE7Th5hsGCw@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect
To: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= <mic@digikod.net>,
	linux-security-module@vger.kernel.org, netdev@vger.kernel.org,
	Eric Dumazet <edumazet@google.com>, =?UTF-8?Q?Günther_Noack?= <gnoack@google.com>,
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>,
	Muhammad Usama Anjum <usama.anjum@collabora.com>, "Serge E . Hallyn" <serge@hallyn.com>,
	yusongping <yusongping@huawei.com>, artem.kuzin@huawei.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Return-Path: netdev+bounces-83463-steffen.klassert=secunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 21:18:06.9907
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: bb0b4948-f2f7-4c56-35b5-08dc5035ba5d
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRVÊs-essen-01.secunet.de:TOTAL-FE=0.005|SMR=0.005(SMRPI=0.003(SMRPI-FrontendProxyAgent=0.003));2024-03-29T21:18:06.996Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 10555
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=Low
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy

On Fri, Mar 29, 2024 at 4:07 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Thu, Mar 28, 2024 at 11:11 AM Ivanov Mikhail
> <ivanov.mikhail1@huawei-partners.com> wrote:
> > On 3/27/2024 3:00 PM, Mickaël Salaün wrote:
> > > Because the security_socket_bind and the security_socket_bind hooks are
> > > called before the network stack, it is easy to introduce error code
> > > inconsistencies. Instead of adding new checks to current and future
> > > LSMs, let's fix the related hook instead. The new checks are already
> > > (partially) implemented by SELinux and Landlock, and it should not
> > > change user space behavior but improve error code consistency instead.
> >
> > It would probably be better to allow the network stack to perform such
> > checks before calling LSM hooks. This may lead to following improvements:
>
> ...
>
> > This may result in adding new method to socket->ops.
>
> I don't think there is a "may result" here, it will *require* a new
> socket::proto_ops function (addr_validate?).  If you want to pursue
> this with the netdev folks to see if they would be willing to adopt
> such an approach I think that would be a great idea.  Just be warned,
> there have been difficulties in the past when trying to get any sort
> of LSM accommodations from the netdev folks.

[Dropping alexey.kodanev@oracle.com due to email errors (unknown recipient)]

I'm looking at the possibility of doing the above and this is slowly
coming back to me as to why we haven't seriously tried this in the
past.  It's not as simple as calling one level down into a proto_ops
function table, the proto_ops function table would then need to jump
down into an associated proto function table.  Granted we aren't
talking per-packet overhead, but I can see this having a measurable
impact on connections/second benchmarks which likely isn't going to be
a welcome change.

-- 
paul-moore.com

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

On Wed, Mar 27, 2024 at 8:00 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.

[Dropping Alexey Kodanev due to email problems]

This isn't something I would want to see backported to the various
stable trees, this is a consolidation and cleanup for future work, not
really a bugfix.  If an individual LSM is currently missing an address
sanity check that should be resolved with a targeted patch that can be
safely backported without affecting other LSMs.

Now, all that doesn't mean I don't think this is a good idea.
Assuming we can't get the network stack to validate addresses before
calling into these LSM hooks, I think this is an improvement over the
current approach.  I would like to see the patchset include individual
patches which do the desired adjustments to the Smack, TOMOYO,
AppArmor, Landlock, and SELinux code now that the sanity checks have
migrated to the LSM layer.  I expect that to be fairly
straightforward, but given all the corner cases I want to make sure
all the individual LSMs are okay with the changes.

> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>  security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

-- 
paul-moore.com

Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect

[Paul Moore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 34042 bytes --]

On Wed, Mar 27, 2024 at 8:00 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.

[Dropping Alexey Kodanev due to email problems]

This isn't something I would want to see backported to the various
stable trees, this is a consolidation and cleanup for future work, not
really a bugfix.  If an individual LSM is currently missing an address
sanity check that should be resolved with a targeted patch that can be
safely backported without affecting other LSMs.

Now, all that doesn't mean I don't think this is a good idea.
Assuming we can't get the network stack to validate addresses before
calling into these LSM hooks, I think this is an improvement over the
current approach.  I would like to see the patchset include individual
patches which do the desired adjustments to the Smack, TOMOYO,
AppArmor, Landlock, and SELinux code now that the sanity checks have
migrated to the LSM layer.  I expect that to be fairly
straightforward, but given all the corner cases I want to make sure
all the individual LSMs are okay with the changes.

> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>  security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

-- 
paul-moore.com

X-sender: <netdev+bounces-83465-steffen.klassert=cunet.com@vger.kernel.org>
X-Receiver: <steffen.klassert@secunet.com> ORCPT=c822;steffen.klassert@secunet.com NOTIFY=VER; X-ExtendedProps=AVABYAAgAAAAUAFAARAPDFCS25BAlDktII2g02frgPADUAAABNaWNyb3NvZnQuRXhjaGFuZ2UuVHJhbnNwb3J0LkRpcmVjdG9yeURhdGEuSXNSZXNvdXJjZQIAAAUAagAJAAEAAAAAAAAABQAWAAIAAAUAQwACAAAFAEYABwADAAAABQBHAAIAAAUAEgAPAGIAAAAvbz1zZWN1bmV0L291PUV4Y2hhbmdlIEFkbWluaXN0cmF0aXZlIEdyb3VwIChGWURJQk9IRjIzU1BETFQpL2NuPVJlY2lwaWVudHMvY249U3RlZmZlbiBLbGFzc2VydDY4YwUACwAXAL4AAACheZxkHSGBRqAcAp3ukbifQ049REI2LENOPURhdGFiYXNlcyxDTj1FeGNoYW5nZSBBZG1pbmlzdHJhdGl2ZSBHcm91cCAoRllESUJPSEYyM1NQRExUKSxDTj1BZG1pbmlzdHJhdGl2ZSBHcm91cHMsQ049c2VjdW5ldCxDTj1NaWNyb3NvZnQgRXhjaGFuZ2UsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1zZWN1bmV0LERDPWRlBQAOABEABiAS9uuMOkqzwmEZDvWNNQUAHQAPAAwAAABtYngtZXNzZW4tMDIFADwAAgAADwA2AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50LkRpc3BsYXlOYW1lDwARAAAAS2xhc3NlcnQsIFN0ZWZmZW4FAAwAAgAABQBsAAIAAAUAWAAXAEoAAADwxQktuQQJQ5LSCNoNNn64Q049S2xhc3NlcnQgU3RlZmZlbixPVT1Vc2VycyxPVT1NaWdyYXRpb24sREM9c2VjdW5ldCxEQz1kZQUAJgACAAEFACIADwAxAAAAQXV0b1Jlc3BvbnNlU3VwcHJlc3M6IDANClRyYW5zbWl0SGlzdG9yeTogRmFsc2UNCg8ALwAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuRXhwYW5zaW9uR3JvdXBUeXBlDwAVAAAATWVtYmVyc0dyb3VwRXhwYW5zaW9uBQAjAAIAAQ=
X-CreatedBy: MSExchange15
X-HeloDomain: a.mx.secunet.com
X-ExtendedProps: BQBjAAoAfEemlidQ3AgFAGEACAABAAAABQA3AAIAAA8APAAAAE1pY3Jvc29mdC5FeGNoYW5nZS5UcmFuc3BvcnQuTWFpbFJlY2lwaWVudC5Pcmdhbml6YXRpb25TY29wZREAAAAAAAAAAAAAAAAAAAAAAAUASQACAAEFAAQAFCABAAAAHAAAAHN0ZWZmZW4ua2xhc3NlcnRAc2VjdW5ldC5jb20FAAYAAgABBQApAAIAAQ8ACQAAAENJQXVkaXRlZAIAAQUAAgAHAAEAAAAFAAMABwAAAAAABQAFAAIAAQUAYgAKAIAAAADMigAABQBkAA8AAwAAAEh1Yg=
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 62.96.220.36
X-EndOfInjectedXHeaders: 16799
Received: from cas-essen-01.secunet.de (10.53.40.201) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=S1_2, cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 22:34:38 +0100
Received: from a.mx.secunet.com (62.96.220.36) by cas-essen-01.secunet.de
 (10.53.40.201) with Microsoft SMTP Server (version=S1_2,
 cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 22:34:38 +0100
Received: from localhost (localhost [127.0.0.1])
	by a.mx.secunet.com (Postfix) with ESMTP id 44D31208AC
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:34:38 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=.751 tagged_above=99 required=1
	tests=AYES_00=.9, DKIM_SIGNED=1, DKIM_VALID=.1,
	DKIM_VALID_AU=.1, HEADER_FROM_DIFFERENT_DOMAINS=249,
	MAILING_LIST_MULTI=, RCVD_IN_DNSWL_NONE=.0001,
	SPF_HELO_NONE=001, SPF_PASS=.001]
	autolearn=available autolearn_force=
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=ss (2048-bit key) header.d=ul-moore.com
Received: from a.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id UmmA5N4cIheh for <steffen.klassert@secunet.com>;
	Fri, 29 Mar 2024 22:34:34 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=ilfrom; client-ip\x147.75.48.161; helo=.mirrors.kernel.org; envelope-from=tdev+bounces-83465-steffen.klassert=cunet.com@vger.kernel.org; receiver=effen.klassert@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 a.mx.secunet.com 53A2720892
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by a.mx.secunet.com (Postfix) with ESMTPS id 53A2720892
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 22:34:34 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sy.mirrors.kernel.org (Postfix) with ESMTPS id 28737B2130B
	for <steffen.klassert@secunet.com>; Fri, 29 Mar 2024 21:34:30 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id 1EA5513BC02;
	Fri, 29 Mar 2024 21:34:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=MHcBIpi"
X-Original-To: netdev@vger.kernel.org
Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33CF51DFC4
	for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 21:34:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=ne smtp.client-ip 9.85.128.179
ARC-Seal: i= a=a-sha256; d=bspace.kernel.org; s=c-20240116;
	t\x1711748061; cv=ne; b=Auqo04ElD606skfooNLm/UZkBKnID82OjkuXK7r/qpuGoXe9BUrYa0DaxnsXRxRTHV6y2x+rArTkYpXvwH7PctJDyt6j2TYdJFf7bsvlDm8TxCcCyxjvrDG7C9kZ0j3tsxirEUCzERxNCB9HqeseliUTavW6oXHxxWHoi7Cp0ARC-Message-Signature: i= a=a-sha256; d=bspace.kernel.org;
	s=c-20240116; t\x1711748061; c=laxed/simple;
	bhPM3LT8mnuywmJNlkQScxlgjVAIlHyjJG8qloVonzuk=
	h=ME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=2K8qmVZqwXtgmr0LI9fUb3Kl8RDqp13AQJ3SEeNG+70ERX+4biYHe1KDkKdbuAWhhgyGdjekI+m/mSUxuyAn3ELn1IZnSUYIlliBepO387THtDsmUygDx4n6Btf5wYOCkqu6pX47jf7TB/8xMPeG4Vo137SLT8XlIecbRVp0kARC-Authentication-Results: i= smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com; spf=ss smtp.mailfrom=ul-moore.com; dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=HcBIpi; arc=ne smtp.client-ip 9.85.128.179
Authentication-Results: smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com
Authentication-Results: smtp.subspace.kernel.org; spf=ss smtp.mailfrom=ul-moore.com
Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-6147942ae18so58177b3.2
        for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 14:34:18 -0700 (PDT)
DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d=ul-moore.com; s=ogle; t\x1711748058; x\x1712352858; darn=er.kernel.org;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MHZaDV3wX5X/mP8vILSA3tsnYggDxtMi+vTwU7OY8=
        b=HcBIpiXyp5v0KrwBJ0Y1s2XnC6BUh97Rt05RbaPDWnQ5yncJbRRQ4bpQ1DvCfFyb
         c087fMlQmqN7DDpRyLBIQqPdsJEiFsuSm2asxqRw4bTPYZs0UUSY9k3tVxa7RLZWr/+H
         +3mbQyr+4wOT8rytF947HQrMh4gAO/EygFRiXqiZvPUNfFGWYRppJUuzj5s1jPwRtPrs
         TrHnXhs6ZqmpBajfXab81hUulMHZOPuxSG2ThE+5NbKs6wfqPACS1RFY7Sl4Sl2OXji5
         T5XKNj2Hy69Q3VTwHuEer0avbRFYAP+/bZBNhSGfatQjGkwMXjxiw4LESd+IPURiJm6J
         6wag=
X-Google-DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d\x1e100.net; s 230601; t\x1711748058; x\x1712352858;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MHZaDV3wX5X/mP8vILSA3tsnYggDxtMi+vTwU7OY8=
        b=HVUfDLC4DWFIfru8+fov/6KGTsW1MmR6xqdgJa0ZwDokwzs6YFo2knHPLWB/ROAL
         qsi5imkejJmFqKZqJ6sr/wejwOAtVNoVNeSGSmqsmSF8Xrcj5HCn1cLMX1Ljqz8qdCGC
         7jG/1seL592tiUukU30+RKaglfpuJ6gYA8jpZGIC0C8HHwJjXEVEti1fT/wY/HS7IMUg
         3kXZN26ymG8e2S0+hqypPJMjEp/QfsQj63frMD5FYcGwyuLOZPrjcyodcvuL5zF4V7/K
         OcG75BYen5EpcUMrXZ8pDrSk6dF5BQZATfBgQXoh3IFejhB6HDgL0jMkSoipydMJOlGV
         /siA=
X-Forwarded-Encrypted: i= AJvYcCV2kKpT1OpsihgTQBlnZylDfTVURRuey4C3HaPv5f5hq0Zk/siPgKCK0ojrUTVaJOOO5yorgBfam6m0wmFQHmfmYXE7iJk6
X-Gm-Message-State: AOJu0YxT4zf6tHhtWM22Kipq7yJ4KbKpQZvdlkAfVQzMIKjgtF1mDEEx
	5kqE6IP9tkZ+/fMDytVoa+erAIUMtN04yXP9N/idtKFzHKFA41775RFtBSrWX6SNVps8rnbPJiL
	YBzrEo71kAusiSQxFArGWWPC3n1HpwyZ1jTZx
X-Google-Smtp-Source: AGHT+IH9pj0gJOAEZqutXLhCgImC4M5PTgqiAEIOD8jNv+vPhXBfVScVMRmBh9ONVHsoONfJu6nKmSY/GEubTYGORdEX-Received: by 2002:a81:84cd:0:b0:609:3c37:a624 with SMTP id
 u196-20020a8184cd000000b006093c37a624mr3517304ywf.35.1711748058196; Fri, 29
 Mar 2024 14:34:18 -0700 (PDT)
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20240327120036.233641-1-mic@digikod.net>
In-Reply-To: <20240327120036.233641-1-mic@digikod.net>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 29 Mar 2024 17:34:07 -0400
Message-ID: <CAHC9VhR42y0BaUPB_BgW+8oadDc36xPJRzEqh9Mwqa1RaMMZXQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect
To: =TF-8?B?TWlja2HDq2wgU2FsYcO8bg==ic@digikod.net>
Cc: linux-security-module@vger.kernel.org, netdev@vger.kernel.org, 
	Eric Dumazet <edumazet@google.com>, =TF-8?Q?Günther_Noack?=noack@google.com>, 
	Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>, 
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>, 
	Muhammad Usama Anjum <usama.anjum@collabora.com>, "Serge E . Hallyn" <serge@hallyn.com>
Content-Type: text/plain; charset=TF-8"
Content-Transfer-Encoding: quoted-printable
Return-Path: netdev+bounces-83465-steffen.klassert=cunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 21:34:38.2980
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: eb6197cb-6771-485d-8d89-08dc5038093a
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.36
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.201
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-01.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRV=x-essen-02.secunet.de:TOTAL-HUB=397|SMR=323(SMRDE=005|SMRC=317(SMRCL=110|X-SMRCR=316))|CAT=073(CATRESL=029
 (CATRESLP2R=006)|CATORES=041(CATRS=041(CATRS-Transport Rule
 Agent=001(X-ETREX=001 )|CATRS-Index Routing
 Agent=039)));2024-03-29T21:34:38.710Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-01.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-FromEntityHeader: Internet
X-MS-Exchange-Organization-OriginalSize: 11561
X-MS-Exchange-Organization-HygienePolicy: Standard
X-MS-Exchange-Organization-MessageLatency: SRVÊs-essen-01.secunet.de:TOTAL-FE=014|SMR=006(SMRPI=004(SMRPI-FrontendProxyAgent=004))|SMS=008
X-MS-Exchange-Organization-Recipient-Limit-Verified: True
X-MS-Exchange-Organization-TotalRecipientCount: 1
X-MS-Exchange-Organization-Rules-Execution-History: 0b0cf904-14ac-4724-8bdf-482ee6223cf2%%%fd34672d-751c-45ae-a963-ed177fcabe23%%%d8080257-b0c3-47b4-b0db-23bc0c8ddb3c%%%95e591a2-5d7d-4afa-b1d0-7573d6c0a5d9%%%f7d0f6bc-4dcc-4876-8c5d-b3d6ddbb3d55%%%16355082-c50b-4214-9c7d-d39575f9f79b
X-MS-Exchange-Forest-RulesExecuted: mbx-essen-02
X-MS-Exchange-Organization-RulesExecuted: mbx-essen-02
X-MS-Exchange-Forest-IndexAgent-0: AQ0CZW4AAaYIAAAPAAADH4sIAAAAAAAEAJVW224byRFtSryJkiwvsg
 GSpzSch5WwFCMLaycRBEOKV06EtS5Y2QmCIDCaM02ylzPTxPSQNBd5
 yP/kIT+Qt/2TIB+SU1UzY0r2IsiCK/dMd1WdOnWqev7zs5tM/8nGfX
 1lcn38674+Pjr+SptC/+bk6Ojff//n+ZW+ctHU/PCPRN+ZxPzwr0yf
 pi46i93YTX08yGzxQi9zX9iT3d4L/PTvbGTmwepiYnWw0Tx3xepd8N
 HUFu+GLou1wf8/ujnxfhq0yS25ikyS2FgP7cjn4hDhlj6f6lCYaNrX
 rtAuaGvCShdeu6zIfTyPrLZ57nMd+ZjduCzyWXChsFnkbBjoywxrE2
 s/0iaOXTaG36WOJjZCbDgCrtxmBSMdzYu5oHl9dxX6OrHFF0GP3HvG
 k9vEFFZgIw67Heg3jLT2iGy0SXJsrcjP/szkhUNqqwPt0lliU8SiNF
 f67uK1y+bvOfBr/Ek8ZUlPyDRM/DyJdeYL5mZisrHVYDrXYWaQ9NBO
 zMIh7+G8IMe5X6wzoT+QsKqhljUjwCOXh0IgE6lm6OGGckxd5lKTaC
 oT6MpBQTYuJtpEkc+ZPVCGg+SI9m0APyZ1yYqYgKsSS7hXdSKfns9f
 vbu8vnjDSZbr5+Spjga2AgUZUR4fFYarsp4G/HvsPsgDnt9e391evC
 whoX7AI+TMcpBGiCgCiZBc+Uzflmi06FMvJzarK7RPEGaQfSal1B7J
 5OGA9ZiZIXRLqCC12FJ/UaqXt4vn9xW8TnpJzwOS9w8vLq//eP6afD
 Hcg6od2IjZp+Ix33T6/NX1zd3b29ubb9+UBgN9Z6n6aepYOcPh6Jl5
 Gh/ZZ/GR3n8SbEIZnehX0PSPMKKXDlhqEsEOOXpA0JOD9ToUE5d/VI
 Z1CQ5BhAWjJbtlBkRrKSLyVOnoJsPep6TCzVXYQA20jw6quobfhYM+
 3KNjuKJUIKTmCx/5RLqS4cGS8sz8cg1/uNfBZetJYUnugRrXjVa1Ii
 HDD81sCodE+0w2sl6ih8xKLw3OwVZqnsgYBDUzU0QTEhx0RLKgEMPc
 ZIhNyt7t/eXr3M9mVOrzxL63K/2Nj01mFzqeMxibGpdQZrBMw1/JRP
 ouZF9gbPjUIg6sL/WS06iABMhiCBXOfE70SRfrhUH152C/hFLk1oa+
 QKVCchF94mLOkosRJdZk8xnTWLYlabwvswqDjxrEgIsx+m6g9SXmbo
 YZFLuFi+cYLcxeqMjE4dQFbnocq9UQTEaaFEkVE1NPxCHNYUBa2FKo
 RhcmH1tKSsjl0xGcDS35GVmEWMucjEieZjSyUUFxRSzlbNntXftln8
 vDjmJvmdkUWYPU2NMDUTxdY2nsPaZ2bA0cnIcwT8ktlAAUOA1wH99n
 VIGFYWZtlTamlPT7bo9uQ3KCa44rFXj4yY3ZB44HCLJq7pIiNf7NZU
 jXM3SGXRNNqB6lMBI3tZUwCB2TFwAVN2gyxxXyoWS7Pd4EvOXEgeFY
 xBPb4HJLLfzdPBQUOVS6ukv5yn5zc3Xz5xv0xvlsdp6nPu8/uOmqCc
 t3FppSOOfZuCaAoHHZIZvUjXOzpl5iJDErm3Na9v0MBS09eBLKyLg8
 WZG4c+PGkwLULk2OAU2NOnYLm5V1pomZZyAtMlSEy7prUgOSAn8TVC
 fvK1lGi59Sy5Ma2Rff1iKmF/ocnZIkfknVFIGi2oEHDo+tsnLc8fXM
 pR1gQh0N7n3g5m+Skrpqcr2MTh4OiVPDz4OpPJ/53KBfB7gPaouL3E
 X663lqvketT20sqzNIePzg5O/xAcitce1JsKfjjP791MnLhcn8Al+P
 0wlNp1PHz4NUnp+eTeZmad0hfQuB5XDP9htMmAJ0u0xf2TCduPh7q0
 +n9dtBWr0t3dyzvppPTJri8+5tMKnR59l381SfzulhYOjhDPM/wYWU
 m3t2t2ae6CtPd+vpDOsz+nOY0ot75+4sZou+GOg/0FzD93CgF2cTfq
 pPvqIvjBN8Tz97ejQ6Hn1lj2O+bOXr50S/9BlKWV4c1NGGhkCBQuDJ
 5iN80T05IEd3bpzZ+NCPRodD2P3vz3EyOjw8pH/qr61fVYtBpP+mf/
 tcf/n//MeunuLiSiolo2HgBF+RSIHuuv0vD0jaFPU+a/RWqQ21uala
 mw21g59qbqhmU7U2GpsdpTqqi19bdbG7p5pY42RL7fKi2W2oz9VWW3
 VwHo8P3rRUe1N12vzbZNuW6iAWfuRfbW6pHs40VXdPfYZdvJGTbT4m
 Idqq11RtdtUUJ7DtqC15rDzvbKntbbVTW3VVb5MSEYedGk+XDRkJ4r
 Zg0lF7eNPiEDgvgXCgy1kAIZPTERJgIh7wl983NxqgaFPSx7pLHraw
 KzCqFBB9RxZ1FBzeInhdAVZjazIPlau2IJd8gbbNux1e8OGW5CInBV
 ibfiCWshafeLOjdlsVnztqTxyuBW1xxQUSyG+vAXj8gB8mrbtW1m3J
 4lNUtDkiYUaglqTGrra4QMLPptquTpZqkfOyu6c+l1IKTsEggAWSGH
 bVIymZWMmxrtqVYwjXUBtiKCY9tS2LDlu1mGe8wbFd9eh+7YCthQW2
 2lx3/GAuUeC5UxZF/FCIOgWsYcW5t0tm2CfMYVXpf2uTt6SaYiKE15
 A4346obr0XhAG8h6s2t2rVdyhZZz1l/FA4xtBieW8/IETEg60e17fm
 FmvpLPHZJnn3ulX5mhXyunxNFlXtE0Vn3jo1jDb3u4iq7mKsJU0ZDs
 1qC0TVIWTRUY9wsqKuJX6oTyv1Vk0Kuh4L21Sahvp52cUQbXejZHsL
 4H7ChZOXMqNw+LNS3t11D7/kElRtRVuAh8kDbf2CFr3aRCoOVy2KWw
 u+jEtio7itqlj0nhkgcmDyuGxnAoNu7bLGhAQhc0vt4fQuN6DAvj+i
 H3d5CjUa2FUbjWcNpYTeTmNrgwd+T/0UGB4JgP8CqGwziGkSAAABCt
 UBPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTE2Ij8+
 DQo8RW1haWxTZXQ+DQogIDxWZXJzaW9uPjE1LjAuMC4wPC9WZXJzaW
 9uPg0KICA8RW1haWxzPg0KICAgIDxFbWFpbCBTdGFydEluZGV4PSI0
 OCI+DQogICAgICA8RW1haWxTdHJpbmc+bWljQGRpZ2lrb2QubmV0PC
 9FbWFpbFN0cmluZz4NCiAgICA8L0VtYWlsPg0KICA8L0VtYWlscz4N
 CjwvRW1haWxTZXQ+AQ7PAVJldHJpZXZlck9wZXJhdG9yLDEwLDA7Um
 V0cmlldmVyT3BlcmF0b3IsMTEsMjtQb3N0RG9jUGFyc2VyT3BlcmF0
 b3IsMTAsMjtQb3N0RG9jUGFyc2VyT3BlcmF0b3IsMTEsMDtQb3N0V2
 9yZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTAsMjtQb3N0V29y
 ZEJyZWFrZXJEaWFnbm9zdGljT3BlcmF0b3IsMTEsMDtUcmFuc3Bvcn
 RXcml0ZXJQcm9kdWNlciwyMCwyMw=
X-MS-Exchange-Forest-IndexAgent: 1 2653
X-MS-Exchange-Forest-EmailMessageHash: 3D17F09A
X-MS-Exchange-Forest-Language: en
X-MS-Exchange-Organization-Processed-By-Journaling: Journal Agent

On Wed, Mar 27, 2024 at 8:00 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.

[Dropping Alexey Kodanev due to email problems]

This isn't something I would want to see backported to the various
stable trees, this is a consolidation and cleanup for future work, not
really a bugfix.  If an individual LSM is currently missing an address
sanity check that should be resolved with a targeted patch that can be
safely backported without affecting other LSMs.

Now, all that doesn't mean I don't think this is a good idea.
Assuming we can't get the network stack to validate addresses before
calling into these LSM hooks, I think this is an improvement over the
current approach.  I would like to see the patchset include individual
patches which do the desired adjustments to the Smack, TOMOYO,
AppArmor, Landlock, and SELinux code now that the sanity checks have
migrated to the LSM layer.  I expect that to be fairly
straightforward, but given all the corner cases I want to make sure
all the individual LSMs are okay with the changes.

> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>  security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

-- 
paul-moore.com

X-sender: <netdev+bounces-83465-peter.schumann=cunet.com@vger.kernel.org>
X-Receiver: <peter.schumann@secunet.com> ORCPT=c822;peter.schumann@secunet.com
X-CreatedBy: MSExchange15
X-HeloDomain: mbx-dresden-01.secunet.de
X-ExtendedProps: BQBjAAoAqUemlidQ3AgFADcAAgAADwA8AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5NYWlsUmVjaXBpZW50Lk9yZ2FuaXphdGlvblNjb3BlEQAAAAAAAAAAAAAAAAAAAAAADwA/AAAATWljcm9zb2Z0LkV4Y2hhbmdlLlRyYW5zcG9ydC5EaXJlY3RvcnlEYXRhLk1haWxEZWxpdmVyeVByaW9yaXR5DwADAAAATG93
X-Source: SMTP:Default MBX-ESSEN-02
X-SourceIPAddress: 10.53.40.199
X-EndOfInjectedXHeaders: 12221
Received: from mbx-dresden-01.secunet.de (10.53.40.199) by
 mbx-essen-02.secunet.de (10.53.40.198) with Microsoft SMTP Server
 (version=S1_2, cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
 15.1.2507.37; Fri, 29 Mar 2024 22:34:33 +0100
Received: from b.mx.secunet.com (62.96.220.37) by cas-essen-02.secunet.de
 (10.53.40.202) with Microsoft SMTP Server (version=S1_2,
 cipher=S_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35 via Frontend
 Transport; Fri, 29 Mar 2024 22:34:33 +0100
Received: from localhost (localhost [127.0.0.1])
	by b.mx.secunet.com (Postfix) with ESMTP id 0D78B2032C
	for <peter.schumann@secunet.com>; Fri, 29 Mar 2024 22:34:33 +0100 (CET)
X-Virus-Scanned: by secunet
X-Spam-Flag: NO
X-Spam-Score: -5.051
X-Spam-Level:
X-Spam-Status: No, score=.051 tagged_above=99 required=1
	tests=AYES_00=.9, DKIM_SIGNED=1, DKIM_VALID=.1,
	DKIM_VALID_AU=.1, HEADER_FROM_DIFFERENT_DOMAINS=249,
	MAILING_LIST_MULTI=, RCVD_IN_DNSWL_MED=.3, SPF_HELO_NONE=001,
	SPF_PASS=.001] autolearn=m autolearn_force=
Authentication-Results: a.mx.secunet.com (amavisd-new);
	dkim=ss (2048-bit key) header.d=ul-moore.com
Received: from b.mx.secunet.com ([127.0.0.1])
	by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 71kp9MtgPhlG for <peter.schumann@secunet.com>;
	Fri, 29 Mar 2024 22:34:29 +0100 (CET)
Received-SPF: Pass (sender SPF authorized) identity=ilfrom; client-ip\x139.178.88.99; helo=.mirrors.kernel.org; envelope-from=tdev+bounces-83465-peter.schumann=cunet.com@vger.kernel.org; receiver=ter.schumann@secunet.com 
DKIM-Filter: OpenDKIM Filter v2.11.0 b.mx.secunet.com 31136200BB
Authentication-Results: b.mx.secunet.com;
	dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=MHcBIpi"
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by b.mx.secunet.com (Postfix) with ESMTPS id 31136200BB
	for <peter.schumann@secunet.com>; Fri, 29 Mar 2024 22:34:29 +0100 (CET)
Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by sv.mirrors.kernel.org (Postfix) with ESMTPS id E1DB1284FF6
	for <peter.schumann@secunet.com>; Fri, 29 Mar 2024 21:34:26 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by smtp.subspace.kernel.org (Postfix) with ESMTP id A16F813B5AE;
	Fri, 29 Mar 2024 21:34:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
	dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=MHcBIpi"
X-Original-To: netdev@vger.kernel.org
Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33CF51DFC4
	for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 21:34:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=ne smtp.client-ip 9.85.128.179
ARC-Seal: i= a=a-sha256; d=bspace.kernel.org; s=c-20240116;
	t\x1711748061; cv=ne; b=Auqo04ElD606skfooNLm/UZkBKnID82OjkuXK7r/qpuGoXe9BUrYa0DaxnsXRxRTHV6y2x+rArTkYpXvwH7PctJDyt6j2TYdJFf7bsvlDm8TxCcCyxjvrDG7C9kZ0j3tsxirEUCzERxNCB9HqeseliUTavW6oXHxxWHoi7Cp0ARC-Message-Signature: i= a=a-sha256; d=bspace.kernel.org;
	s=c-20240116; t\x1711748061; c=laxed/simple;
	bhPM3LT8mnuywmJNlkQScxlgjVAIlHyjJG8qloVonzuk=
	h=ME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=2K8qmVZqwXtgmr0LI9fUb3Kl8RDqp13AQJ3SEeNG+70ERX+4biYHe1KDkKdbuAWhhgyGdjekI+m/mSUxuyAn3ELn1IZnSUYIlliBepO387THtDsmUygDx4n6Btf5wYOCkqu6pX47jf7TB/8xMPeG4Vo137SLT8XlIecbRVp0kARC-Authentication-Results: i= smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com; spf=ss smtp.mailfrom=ul-moore.com; dkim=ss (2048-bit key) header.d=ul-moore.com header.i=aul-moore.com header.b=HcBIpi; arc=ne smtp.client-ip 9.85.128.179
Authentication-Results: smtp.subspace.kernel.org; dmarc=ss (p=ne dis=ne) header.from=ul-moore.com
Authentication-Results: smtp.subspace.kernel.org; spf=ss smtp.mailfrom=ul-moore.com
Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-6147942ae18so58177b3.2
        for <netdev@vger.kernel.org>; Fri, 29 Mar 2024 14:34:18 -0700 (PDT)
DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d=ul-moore.com; s=ogle; t\x1711748058; x\x1712352858; darn=er.kernel.org;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:from:to:cc:subject:date
         :message-id:reply-to;
        bh=MHZaDV3wX5X/mP8vILSA3tsnYggDxtMi+vTwU7OY8=
        b=HcBIpiXyp5v0KrwBJ0Y1s2XnC6BUh97Rt05RbaPDWnQ5yncJbRRQ4bpQ1DvCfFyb
         c087fMlQmqN7DDpRyLBIQqPdsJEiFsuSm2asxqRw4bTPYZs0UUSY9k3tVxa7RLZWr/+H
         +3mbQyr+4wOT8rytF947HQrMh4gAO/EygFRiXqiZvPUNfFGWYRppJUuzj5s1jPwRtPrs
         TrHnXhs6ZqmpBajfXab81hUulMHZOPuxSG2ThE+5NbKs6wfqPACS1RFY7Sl4Sl2OXji5
         T5XKNj2Hy69Q3VTwHuEer0avbRFYAP+/bZBNhSGfatQjGkwMXjxiw4LESd+IPURiJm6J
         6wag=
X-Google-DKIM-Signature: v= a=a-sha256; c=laxed/relaxed;
        d\x1e100.net; s 230601; t\x1711748058; x\x1712352858;
        h=ntent-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
         :subject:date:message-id:reply-to;
        bh=MHZaDV3wX5X/mP8vILSA3tsnYggDxtMi+vTwU7OY8=
        b=HVUfDLC4DWFIfru8+fov/6KGTsW1MmR6xqdgJa0ZwDokwzs6YFo2knHPLWB/ROAL
         qsi5imkejJmFqKZqJ6sr/wejwOAtVNoVNeSGSmqsmSF8Xrcj5HCn1cLMX1Ljqz8qdCGC
         7jG/1seL592tiUukU30+RKaglfpuJ6gYA8jpZGIC0C8HHwJjXEVEti1fT/wY/HS7IMUg
         3kXZN26ymG8e2S0+hqypPJMjEp/QfsQj63frMD5FYcGwyuLOZPrjcyodcvuL5zF4V7/K
         OcG75BYen5EpcUMrXZ8pDrSk6dF5BQZATfBgQXoh3IFejhB6HDgL0jMkSoipydMJOlGV
         /siA=
X-Forwarded-Encrypted: i= AJvYcCV2kKpT1OpsihgTQBlnZylDfTVURRuey4C3HaPv5f5hq0Zk/siPgKCK0ojrUTVaJOOO5yorgBfam6m0wmFQHmfmYXE7iJk6
X-Gm-Message-State: AOJu0YxT4zf6tHhtWM22Kipq7yJ4KbKpQZvdlkAfVQzMIKjgtF1mDEEx
	5kqE6IP9tkZ+/fMDytVoa+erAIUMtN04yXP9N/idtKFzHKFA41775RFtBSrWX6SNVps8rnbPJiL
	YBzrEo71kAusiSQxFArGWWPC3n1HpwyZ1jTZx
X-Google-Smtp-Source: AGHT+IH9pj0gJOAEZqutXLhCgImC4M5PTgqiAEIOD8jNv+vPhXBfVScVMRmBh9ONVHsoONfJu6nKmSY/GEubTYGORdEX-Received: by 2002:a81:84cd:0:b0:609:3c37:a624 with SMTP id
 u196-20020a8184cd000000b006093c37a624mr3517304ywf.35.1711748058196; Fri, 29
 Mar 2024 14:34:18 -0700 (PDT)
Precedence: bulk
X-Mailing-List: netdev@vger.kernel.org
List-Id: <netdev.vger.kernel.org>
List-Subscribe: <mailto:netdev+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:netdev+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
References: <20240327120036.233641-1-mic@digikod.net>
In-Reply-To: <20240327120036.233641-1-mic@digikod.net>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 29 Mar 2024 17:34:07 -0400
Message-ID: <CAHC9VhR42y0BaUPB_BgW+8oadDc36xPJRzEqh9Mwqa1RaMMZXQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/2] lsm: Check and handle error priority for
 socket_bind and socket_connect
To: =TF-8?B?TWlja2HDq2wgU2FsYcO8bg==ic@digikod.net>
Cc: linux-security-module@vger.kernel.org, netdev@vger.kernel.org, 
	Eric Dumazet <edumazet@google.com>, =TF-8?Q?Günther_Noack?=noack@google.com>, 
	Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>, 
	Konstantin Meskhidze <konstantin.meskhidze@huawei.com>, 
	Muhammad Usama Anjum <usama.anjum@collabora.com>, "Serge E . Hallyn" <serge@hallyn.com>
Content-Type: text/plain; charset=TF-8"
Content-Transfer-Encoding: quoted-printable
Return-Path: netdev+bounces-83465-peter.schumann=cunet.com@vger.kernel.org
X-MS-Exchange-Organization-OriginalArrivalTime: 29 Mar 2024 21:34:33.0961
 (UTC)
X-MS-Exchange-Organization-Network-Message-Id: d5cfd638-bc6c-43a4-f38f-08dc50380620
X-MS-Exchange-Organization-OriginalClientIPAddress: 62.96.220.37
X-MS-Exchange-Organization-OriginalServerIPAddress: 10.53.40.202
X-MS-Exchange-Organization-Cross-Premises-Headers-Processed: cas-essen-02.secunet.de
X-MS-Exchange-Organization-OrderedPrecisionLatencyInProgress: LSRVÊs-essen-02.secunet.de:TOTAL-FE=026|SMR=025(SMRPI=022(SMRPI-FrontendProxyAgent=022));2024-03-29T21:34:33.122Z
X-MS-Exchange-Forest-ArrivalHubServer: mbx-essen-02.secunet.de
X-MS-Exchange-Organization-AuthSource: cas-essen-02.secunet.de
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-OriginalSize: 11672
X-MS-Exchange-Organization-Transport-Properties: DeliveryPriority=w
X-MS-Exchange-Organization-Prioritization: 2:ShadowRedundancy
X-MS-Exchange-Organization-IncludeInSla: False:ShadowRedundancy

On Wed, Mar 27, 2024 at 8:00 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> Because the security_socket_bind and the security_socket_bind hooks are
> called before the network stack, it is easy to introduce error code
> inconsistencies. Instead of adding new checks to current and future
> LSMs, let's fix the related hook instead. The new checks are already
> (partially) implemented by SELinux and Landlock, and it should not
> change user space behavior but improve error code consistency instead.
>
> The first check is about the minimal sockaddr length according to the
> address family. This improves the security of the AF_INET and AF_INET6
> sockaddr parsing for current and future LSMs.
>
> The second check is about AF_UNSPEC. This fixes error priority for bind
> on PF_INET6 socket when SELinux (and potentially others) is enabled.
> Indeed, the IPv6 network stack first checks the sockaddr length (-EINVAL
> error) before checking the family (-EAFNOSUPPORT error). See commit
> bbf5a1d0e5d0 ("selinux: Fix error priority for bind with AF_UNSPEC on
> PF_INET6 socket").
>
> The third check is about consistency between socket family and address
> family. Only AF_INET and AF_INET6 are tested (by Landlock tests), so no
> other protocols are checked for now.
>
> These new checks should enable to simplify current LSM implementations,
> but we may want to first land this patch on all stable branches.

[Dropping Alexey Kodanev due to email problems]

This isn't something I would want to see backported to the various
stable trees, this is a consolidation and cleanup for future work, not
really a bugfix.  If an individual LSM is currently missing an address
sanity check that should be resolved with a targeted patch that can be
safely backported without affecting other LSMs.

Now, all that doesn't mean I don't think this is a good idea.
Assuming we can't get the network stack to validate addresses before
calling into these LSM hooks, I think this is an improvement over the
current approach.  I would like to see the patchset include individual
patches which do the desired adjustments to the Smack, TOMOYO,
AppArmor, Landlock, and SELinux code now that the sanity checks have
migrated to the LSM layer.  I expect that to be fairly
straightforward, but given all the corner cases I want to make sure
all the individual LSMs are okay with the changes.

> A following patch adds new tests improving AF_UNSPEC test coverage for
> Landlock.
>
> Cc: Alexey Kodanev <alexey.kodanev@oracle.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Günther Noack <gnoack@google.com>
> Cc: Ivanov Mikhail <ivanov.mikhail1@huawei-partners.com>
> Cc: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Paul Moore <paul@paul-moore.com>
> Cc: Serge E. Hallyn <serge@hallyn.com>
> Fixes: 20510f2f4e2d ("security: Convert LSM into a static interface")
> Signed-off-by: Mickaël Salaün <mic@digikod.net>
> ---
>  security/security.c | 96 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

-- 
paul-moore.com