lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Oct 2022 13:43:15 -0400 From: Paul Moore <paul@...l-moore.com> To: Martin KaFai Lau <martin.lau@...nel.org> Cc: Alexei Starovoitov <ast@...nel.org>, netdev@...r.kernel.org, linux-security-module@...r.kernel.org, selinux@...r.kernel.org Subject: Re: SO_PEERSEC protections in sk_getsockopt()? On Wed, Oct 5, 2022 at 4:44 PM Paul Moore <paul@...l-moore.com> wrote: > > Hi Martin, > > In commit 4ff09db1b79b ("bpf: net: Change sk_getsockopt() to take the > sockptr_t argument") I see you wrapped the getsockopt value/len > pointers with sockptr_t and in the SO_PEERSEC case you pass the > sockptr_t:user field to avoid having to update the LSM hook and > implementations. I think that's fine, especially as you note that > eBPF does not support fetching the SO_PEERSEC information, but I think > it would be good to harden this case to prevent someone from calling > sk_getsockopt(SO_PEERSEC) with kernel pointers. What do you think of > something like this? > > static int sk_getsockopt(...) > { > /* ... */ > case SO_PEERSEC: > if (optval.is_kernel || optlen.is_kernel) > return -EINVAL; > return security_socket_getpeersec_stream(...); > /* ... */ > } Any thoughts on this Martin, Alexei? It would be nice to see this fixed soon ... -- paul-moore.com
Powered by blists - more mailing lists