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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAHC9VhTGE1cf_WtDn4aDUY=E-m--4iZXWiNTwPZrP9AVoq17cw@mail.gmail.com> Date: Wed, 5 Oct 2022 16:44:46 -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: SO_PEERSEC protections in sk_getsockopt()? 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(...); /* ... */ } -- paul-moore.com
Powered by blists - more mailing lists