qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] feature idea: allow user to run custom scripts


From: Programmingkid
Subject: Re: [Qemu-devel] feature idea: allow user to run custom scripts
Date: Fri, 2 Oct 2015 09:28:53 -0400

On Oct 2, 2015, at 8:33 AM, Daniel P. Berrange wrote:

> On Wed, Sep 30, 2015 at 11:53:50AM +0100, Peter Maydell wrote:
>> On 30 September 2015 at 09:14, Dr. David Alan Gilbert
>> <address@hidden> wrote:
>>> * Markus Armbruster (address@hidden) wrote:
>>>> In my opinion, QEMU should leave them to separate GUI shells, because
>>>> doing everything in QEMU distracts from our core mission and we don't
>>>> have GUI expertise[*].  One more point: building in the GUI is
>>>> problematic when you don't trust the guest, because then you really want
>>>> to run QEMU with least privileges.
>>> 
>>> Given that we have a built in GUI then I can see people wanting to expand
>>> it.
>> 
>> Right, but where do you draw the line? We clearly don't have the
>> active maintainer and review capacity to do anything serious with
>> "ui/" (MAINTAINERS lists everything except SPICE as Odd Fixes).
>> 
>> This is why I tend to agree with Markus' opinion here: we should
>> provide enough graphical UI to make raw QEMU minimally usable,
>> and leave further user-friendliness to other projects which have
>> more direct interest in that.
>> 
>> If we had more regular contributors who were actively interested
>> in improving our UI layer my opinion might be different.
> 
> Even if we had more contributors interested in that, I still think
> that we should not do it, because building a UI into QEMU is a
> fundamentally bad design / architecture.

Why is it a bad design? I know that the Linux custom is to make a command
then possibly make a GUI that wraps around the command, but QEMU
doesn't just run on Linux. It runs on Mac OS X, Windows, Solaris,
FreeBSD, and maybe some more OS's. Applying the design
decisions of one OS to all OS's isn't necessarily a good idea

> QEMU is a security
> sensitive component and we want to know the boundaries of what
> a guest exploit can achieve - including a GUI massively expands
> the attack surface making it more or less impossible to confine
> any QEMU exploit, even with tools like SELinux/AppArmour, because
> you have to allow use of the desktop protocol at which point you
> can just talk to a separate app to perform the exploit.

The answer is simple in this situation. Just don't run a GUI with QEMU.
There is --disable-sdl, --disable-gtk, and --disable-cocoa. No more
GUI - security problems solved. 




reply via email to

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