Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface

[Alex Bennée]

Daniel P. Berrangé <address@hidden> writes:

> On Thu, Jul 04, 2019 at 10:16:20AM +0100, Alex Bennée wrote:
>>
>> Daniel P. Berrangé <address@hidden> writes:
>>
>> > On Wed, Jul 03, 2019 at 10:56:05PM +0100, Alex Bennée wrote:
>> >>
>> >> Daniel P. Berrangé <address@hidden> writes:
>> <snip>
>> >> > The reality is that the monitor console (whether QMP or HMP) is
>> >> > considered a privileged interface to QEMU and as such must only
>> >> > be made available to trusted users. IOW, making it available with
>> >> > no authentication over TCP is simply a, very serious, user
>> >> > configuration error not a security flaw in QEMU itself.
>> >>
>> >> Is this the sort of thing we should emit warnings for? I guess this is a
>> >> philosophical question as QEMU tends to err towards being taciturn on
>> >> the command line unless something is actually wrong (and not just
>> >> stupid).
>> >>
>> >> I wouldn't expect a warning for -serial mon:stdio but maybe a
>> >> non-localhost tcp chardev for o+rw socket might be worth a mention? Of
>> >> course this sort of sanitising of the command line options does incur
>> >> cost and complexity in our option processing.
>> >
>> > The challenge with issuing warnings is ensuring that we don't give
>> > false positives, and that's pretty much impossible IMHO.
>> >
>> > Even use of plain non-localhost TCP chardevs can be valid in some
>> > circumstances. For example it would not be surprising to see it
>> > used if QEMU was inside a Kubernetes container, as two containers
>> > can communicate with each other over IP & rely on Kubernetes
>> > networking layer to provide security
>>
>> That's certainly a valid setup - you're right this is really a policy
>> question. Oh well I guess if your serious about security you read the
>> documentation before going to production right ;-)
>>
>> I assume libvirt et all strive to use secure configurations by default?
>
> Yes, libvirt exclusively uses a UNIX domain socket for the monitor, and
> of course even if we used a TCP socket, the SELinux/AppArmour policy
> will block any attempts at elevating privs via QMP commands that spawn
> processes or try to access arbitrary files.

Maybe this would make a good topic for a QEMU blog post?

--
Alex Bennée