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: <CAHC9VhTBdLtK_spOS9axuYfHRb=zx3TFqKY2cvfy9tRd0ep-sg@mail.gmail.com> Date: Mon, 10 Oct 2022 11:56:14 -0400 From: Paul Moore <paul@...l-moore.com> To: David Laight <David.Laight@...lab.com> Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, Martin KaFai Lau <martin.lau@...nel.org>, Alexei Starovoitov <ast@...nel.org>, Network Development <netdev@...r.kernel.org>, LSM List <linux-security-module@...r.kernel.org>, "selinux@...r.kernel.org" <selinux@...r.kernel.org> Subject: Re: SO_PEERSEC protections in sk_getsockopt()? On Mon, Oct 10, 2022 at 11:34 AM David Laight <David.Laight@...lab.com> wrote: > From: Paul Moore > > Sent: 10 October 2022 14:19 > .... > > > It isn't really ideal for the buffer pointer either. > > > That started as a single field (assuming the caller > > > has verified the user/kernel status), then the is_kernel > > > field was added for architectures where user/kernel > > > addresses use the same values. > > > Then a horrid bug (forgotten where) forced the is_kernel > > > field be used everywhere. > > > Again a structure with two pointers would be much safer. > > > > Any chance you have plans to work on this David? > > I'd only spend any significant time on it if there > is a reasonable chance of the patches being accepted. > > My use would be an out-of-tree non-GPL module calling > kernel_getsockopt(). > The main in-tree user is bpf - which seems to need an > ever-increasing number of socket options, but support has > been added one by one. > > While most getsockopt() calls just return set values, SCTP > uses some to retrieve the result of values negotiated with > the peer. The number of valid data streams is needed for > even trivial SCTP applications. > However I've a workaround for a bug in 5.1 to 5.8 that > returned the wrong values (my tests didn't check negotiation) > that also obtains the values on later kernels. > So I'm not (yet) in a hurry! It looks like it might still be a good idea to add hardening/support for the LSM hook as your needs still seem a bit far off, but I appreciate the background - thanks! -- paul-moore.com
Powered by blists - more mailing lists