linux-kernel - Re: [PATCH 00/10] RFC: SO_PEERCRED for AF

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:   Thu, 21 Oct 2021 15:34:25 +0200
From:   Stefano Garzarella <sgarzare@...hat.com>
To:     Marc-André Lureau <marcandre.lureau@...hat.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        davem@...emloft.net, kuba@...nel.org
Subject: Re: [PATCH 00/10] RFC: SO_PEERCRED for AF_VSOCK

Hi,

On Thu, Oct 21, 2021 at 04:37:04PM +0400, Marc-André Lureau wrote:
>Hi,
>
>This RFC aims to implement some support for SO_PEERCRED with AF_VSOCK,
>so vsock servers & clients can lookup the basic peer credentials.
>(further support for SO_PEERSEC could also be useful)

Thanks for this RFC! Just had a quick look, Monday I hope to give you 
better feedback :-)

>
>This is pretty straightforward for loopback transport, where both ends
>are on the same host.
>
>For vhost transport, the host will set the peer credentials associated with
>the process who called VHOST_SET_OWNER (ex QEMU).
>
>For virtio transport, the credentials are cleared upon connect, as
>providing foreign credentials wouldn't make much sense.
>
>I haven't looked at other transports. What do you think of this 
>approach?

So IIUC, SO_PEERCRED will make sense only in the host and will return 
the credentials of the VMM (e.g. QEMU) that manages the VM of the peer 
to which we are connected.

So the features should be supported by the following type of transports:
- VSOCK_TRANSPORT_F_LOCAL (vsock_loopback)
- VSOCK_TRANSPORT_F_H2G (vhost-vsock, vmci)

>
>Note: I think it would be a better to set the peer credentials when we
>actually can provide them, rather than at creation time, but I haven't
>found a way yet. Help welcome!

Yep, I agree, cleaning credentials after connecting in the guest seems a 
bit strange.
As you also said, would be better to set them only after a successful 
connect(), which should be similar to what AF_UNIX does.

Maybe we can add an helper in af_vsock.c that will be called from the 
transports that support this feature at the end the connection setup.

I'll think better of it and get back to you.

Thanks,
Stefano