* [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-27 12:00 Mickaël Salaün 2024-03-27 12:00 ` [PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests Mickaël Salaün ` (3 more replies) 0 siblings, 4 replies; 10+ messages in thread From: Mickaël Salaün @ 2024-03-27 12:00 UTC (permalink / raw) To: Paul Moore Cc: Mickaël Salaün, linux-security-module, netdev, Alexey Kodanev, Eric Dumazet, Günther Noack, Ivanov Mikhail, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests 2024-03-27 12:00 [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Mickaël Salaün @ 2024-03-27 12:00 ` Mickaël Salaün 2024-03-27 16:41 ` [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Casey Schaufler ` (2 subsequent siblings) 3 siblings, 0 replies; 10+ messages in thread From: Mickaël Salaün @ 2024-03-27 12:00 UTC (permalink / raw) To: Paul Moore Cc: Mickaël Salaün, linux-security-module, netdev, Eric Dumazet, Günther Noack, Ivanov Mikhail, Konstantin Meskhidze, Serge E . Hallyn 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect 2024-03-27 12:00 [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Mickaël Salaün 2024-03-27 12:00 ` [PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests Mickaël Salaün @ 2024-03-27 16:41 ` Casey Schaufler 2024-03-28 15:10 ` Ivanov Mikhail 2024-03-29 21:34 ` Paul Moore 3 siblings, 0 replies; 10+ messages in thread From: Casey Schaufler @ 2024-03-27 16:41 UTC (permalink / raw) To: Mickaël Salaün, Paul Moore Cc: linux-security-module, netdev, Alexey Kodanev, Eric Dumazet, Günther Noack, Ivanov Mikhail, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, 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); > } > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect 2024-03-27 12:00 [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Mickaël Salaün 2024-03-27 12:00 ` [PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests Mickaël Salaün 2024-03-27 16:41 ` [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Casey Schaufler @ 2024-03-28 15:10 ` Ivanov Mikhail 2024-03-29 20:07 ` Paul Moore 2024-03-29 21:34 ` Paul Moore 3 siblings, 1 reply; 10+ messages in thread From: Ivanov Mikhail @ 2024-03-28 15:10 UTC (permalink / raw) To: Mickaël Salaün, Paul Moore Cc: linux-security-module, netdev, Alexey Kodanev, Eric Dumazet, Günther Noack, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, yusongping, artem.kuzin 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); > } > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect 2024-03-28 15:10 ` Ivanov Mikhail @ 2024-03-29 20:07 ` Paul Moore 2024-03-29 21:17 ` Paul Moore 0 siblings, 1 reply; 10+ messages in thread From: Paul Moore @ 2024-03-29 20:07 UTC (permalink / raw) To: Ivanov Mikhail Cc: Mickaël Salaün, linux-security-module, netdev, Alexey Kodanev, Eric Dumazet, Günther Noack, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, yusongping, artem.kuzin 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-29 21:17 ` Paul Moore 0 siblings, 0 replies; 10+ messages in thread From: Paul Moore @ 2024-03-29 21:17 UTC (permalink / raw) To: Ivanov Mikhail Cc: Mickaël Salaün, linux-security-module, netdev, Eric Dumazet, Günther Noack, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, yusongping, artem.kuzin 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-29 21:17 ` Paul Moore 0 siblings, 0 replies; 10+ messages in thread From: Paul Moore @ 2024-03-29 21:17 UTC (permalink / raw) To: Ivanov Mikhail Cc: Mickaël Salaün, linux-security-module, netdev, Eric Dumazet, Günther Noack, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, yusongping, artem.kuzin [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-29 21:17 ` Paul Moore 0 siblings, 0 replies; 10+ messages in thread From: Paul Moore @ 2024-03-29 21:17 UTC (permalink / raw) To: Ivanov Mikhail Cc: Mickaël Salaün, linux-security-module, netdev, Eric Dumazet, Günther Noack, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn, yusongping, artem.kuzin [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-29 21:34 ` Paul Moore 0 siblings, 0 replies; 10+ messages in thread From: Paul Moore @ 2024-03-29 21:34 UTC (permalink / raw) To: Mickaël Salaün Cc: linux-security-module, netdev, Eric Dumazet, Günther Noack, Ivanov Mikhail, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect @ 2024-03-29 21:34 ` Paul Moore 0 siblings, 0 replies; 10+ messages in thread From: Paul Moore @ 2024-03-29 21:34 UTC (permalink / raw) To: Mickaël Salaün Cc: linux-security-module, netdev, Eric Dumazet, Günther Noack, Ivanov Mikhail, Konstantin Meskhidze, Muhammad Usama Anjum, Serge E . Hallyn [-- 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2024-03-31 16:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-27 12:00 [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Mickaël Salaün 2024-03-27 12:00 ` [PATCH v1 2/2] selftests/landlock: Improve AF_UNSPEC tests Mickaël Salaün 2024-03-27 16:41 ` [PATCH v1 1/2] lsm: Check and handle error priority for socket_bind and socket_connect Casey Schaufler 2024-03-28 15:10 ` Ivanov Mikhail 2024-03-29 20:07 ` Paul Moore 2024-03-29 21:17 ` Paul Moore 2024-03-29 21:17 ` Paul Moore 2024-03-29 21:17 ` Paul Moore 2024-03-29 21:34 ` Paul Moore 2024-03-29 21:34 ` Paul Moore
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.