On 6/21/2024 12:41 PM, Paul Moore wrote:
> On Fri, Jun 21, 2024 at 12:06 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote:
>> On 6/20/2024 2:05 PM, Paul Moore wrote:
>>> On May 13, 2024 Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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
>
