Daniel P. Berrangé <berra...@redhat.com> writes:
> On Wed, Jul 03, 2019 at 10:56:05PM +0100, Alex Bennée wrote: >> >> Daniel P. Berrangé <berra...@redhat.com> 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
