qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Alex Bennée
Subject: Re: [Qemu-devel] [PATCH] doc: document that the monitor console is a privileged control interface
Date: Thu, 04 Jul 2019 10:16:20 +0100
User-agent: mu4e 1.3.2; emacs 26.1

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?

>
> Regards,
> Daniel


--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]