netdev - RE: SO_PEERSEC protections in sk

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Oct 2022 15:34:24 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Paul Moore' <paul@...l-moore.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()?

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!

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)