On 01/09/2020 11:19, Daniel P. Berrangé wrote:
On Tue, Sep 01, 2020 at 12:11:11PM +0200, Christian Ehrhardt wrote:
> On Thu, May 28, 2020 at 12:45 PM Simon Arlott <libvirt(a)octiron.net> wrote:
>>
>> The VM does not need read permission for its own sockets to create,
>> bind(), listen(), accept() connections or to recv(), send(), etc. on
>> those connections.
>>
>> This was fixed in ab9569e5460d1e4737fe8b625c67687dc2204665
>> (virt-aa-helper: disallow VNC socket read permissions),
>> but then b6465e1aa49397367a9cd0f27110b9c2280a7385
>> (graphics: introduce new listen type 'socket')
>> and acc83afe333bfadd3f7f79091d38ca3d7da1eeb2
>> (acc83afe333bfadd3f7f79091d38ca3d7da1eeb2) reverted it.
>>
>> Unless the read permission is omitted, VMs can connect to each other's
>> VNC/graphics sockets.
snip
> And as I said the concern of "VMs can connect to each other" would
> only be true if the admin specifies the same path in each of them
> intentionally.
Protecting against administrator mis-configurations is NOT a goal
of the security drivers. We're only aiming to protect against a
compromised QEMU in whatever configuration the admin requested.
Searching the libvirt documentation for "directory", I cannot find any
information that using the same directory for the VNC path of multiple
VMs (or any other files) is an "administrator mis-configuration".
There is no reason to grant more permissions than are necessary. We
don't grant write permission to all files that need to be read so why
should we grant connect (read) permission to all sockets that need to
be used for listening (write permission)?
--
Simon Arlott