[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221013085333.26288e44@kernel.org>
Date: Thu, 13 Oct 2022 08:53:33 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paul Moore <paul@...l-moore.com>
Cc: linux-security-module@...r.kernel.org, selinux@...r.kernel.org,
netdev@...r.kernel.org,
Alexei Starovoitov <alexei.starovoitov@...il.com>
Subject: Re: [PATCH] lsm: make security_socket_getpeersec_stream() sockptr_t
safe
On Mon, 10 Oct 2022 17:58:29 -0400 Paul Moore wrote:
> Commit 4ff09db1b79b ("bpf: net: Change sk_getsockopt() to take the
> sockptr_t argument") made it possible to call sk_getsockopt()
> with both user and kernel address space buffers through the use of
> the sockptr_t type. Unfortunately at the time of conversion the
> security_socket_getpeersec_stream() LSM hook was written to only
> accept userspace buffers, and in a desire to avoid having to change
> the LSM hook the commit author simply passed the sockptr_t's
> userspace buffer pointer. Since the only sk_getsockopt() callers
> at the time of conversion which used kernel sockptr_t buffers did
> not allow SO_PEERSEC, and hence the
> security_socket_getpeersec_stream() hook, this was acceptable but
> also very fragile as future changes presented the possibility of
> silently passing kernel space pointers to the LSM hook.
>
> There are several ways to protect against this, including careful
> code review of future commits, but since relying on code review to
> catch bugs is a recipe for disaster and the upstream eBPF maintainer
> is "strongly against defensive programming", this patch updates the
> LSM hook, and all of the implementations to support sockptr_t and
> safely handle both user and kernel space buffers.
Code seems sane, FWIW, but the commit message sounds petty,
which is likely why nobody is willing to ack it.
Powered by blists - more mailing lists