Daniel P. Berrangé <berra...@redhat.com> writes:
> On Thu, Jul 04, 2019 at 10:16:20AM +0100, Alex Bennée wrote: >> >> 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? > > 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
