[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2cddc480-f911-44e3-b415-33e0cec2964c@schaufler-ca.com>
Date: Fri, 21 Jun 2024 15:00:22 -0700
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.com>
Cc: LSM List <linux-security-module@...r.kernel.org>, netdev@...r.kernel.org,
linux-api@...r.kernel.org,
Linux kernel mailing list <linux-kernel@...r.kernel.org>,
Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH RFC] LSM, net: Add SO_PEERCONTEXT for peer LSM data
On 6/21/2024 12:41 PM, Paul Moore wrote:
> On Fri, Jun 21, 2024 at 12:06 PM Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 6/20/2024 2:05 PM, Paul Moore wrote:
>>> On May 13, 2024 Casey Schaufler <casey@...aufler-ca.com> wrote:
> ..
>
>>>> +/**
>>>> + * security_socket_getpeerctx_stream() - Get the remote peer label
>>>> + * @sock: socket
>>>> + * @optval: destination buffer
>>>> + * @optlen: size of peer label copied into the buffer
>>>> + * @len: maximum size of the destination buffer
>>>> + *
>>>> + * This hook allows the security module to provide peer socket security state
>>>> + * for unix or connected tcp sockets to userspace via getsockopt
>>>> + * SO_GETPEERCONTEXT. For tcp sockets this can be meaningful if the socket
>>>> + * is associated with an ipsec SA.
>>>> + *
>>>> + * Return: Returns 0 if all is well, otherwise, typical getsockopt return
>>>> + * values.
>>>> + */
>>>> +int security_socket_getpeerctx_stream(struct socket *sock, sockptr_t optval,
>>>> + sockptr_t optlen, unsigned int len)
>>>> +{
>>>> + struct security_hook_list *hp;
>>>> +
>>>> + hlist_for_each_entry(hp, &security_hook_heads.socket_getpeerctx_stream,
>>>> + list)
>>>> + return hp->hook.socket_getpeerctx_stream(sock, optval, optlen,
>>>> + len);
>>>> +
>>>> + return LSM_RET_DEFAULT(socket_getpeerctx_stream);
>>>> +}
>>> Don't we need the same magic that we have in security_getselfattr() to
>>> handle the multi-LSM case?
>> Yes. I would like to move this ahead independently of the multi-LSM support.
>> Putting the multi-LSM magic in is unnecessary and rather pointless until then.
> Starting with the LSM syscalls, I want any new user visible API that
> can support multiple LSMs to have support for multiple LSMs. Yes, the
> setselfattr API doesn't support multiple LSMs, but that is because we
> agreed there was never going to be a way to safely support that usage.
> In this particular case, that same argument does not apply, we could
> have multiple LSMs returning a socket's network peer information (even
> if we don't currently see that), so let's make sure our API supports
> it from the start.
OK. I'll put that in v2 as well.
>
> Unrelated to the above, it would also be good to datagram support as a
> patch 2/2 thing in a future version of this patchset. Please be
> careful not to carry over the mistakes we made with SCM_SECURITY (see
> the GH discussion linked below).
That's "in my queue". I didn't want to spend time on it until I got
feedback on this one.
>
> * https://github.com/SELinuxProject/selinux-kernel/issues/24
>
Powered by blists - more mailing lists