Qubes is based on Xen. There are templates for Fedora, Debian and others.
Windows can be a guest VM. Windows as a host is only a theoretical
consideration for a theoretical port. [Hypervisor Abstraction Layer (HAL)]
What convinced me of Qubes is, that for Linux a single explorable wifi
driver is enough to already own everything, while with Qubes this code
runs in a dedicated NetVM.
For implementation details, see this pdf.
https://www.qubes-os.org/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf
It has a chapter "Secure GUI".
Elmar Stellnberger:
No actually it is not Qubes what I am using.
I am using full blown qemu virtualization including a virtual wrapper
device for the graphics. It is for sure that even here the weakest point
is the emulation of the graphics card. I have even heard about HTML5
code directly bugging your hardware via graphics acceleration (though
this is rather theoretical because it would likely need to be customized
to a certain graphics card). Nonetheless the weakness of Qubes is even
more the GUI dom where all other doms connect to and which has direct
access to the graphics hardware. Unfortunately I could not find any
details on how it is implemented in deed.
Additionally I found it somewhat irritating that the basic description
of the Qubes project talks so much about using Windows as a host. I
would never trust software which is entirely closed source. Please do
also note the following statement found in the intro when considering to
use Qubes:
"Sure, a single kernel exploit destroys this all"
If you remember what I have told you about MAC systems then it was that
a single public accessible system call which is implemented faulty would
still compromise your system. Now consider that all current operating
systems including Windows, Linux and FreeBSD are huge monolitic
constructs making use of just two privilege levels/ security rings: user
and kernel mode. At the introduction of the i386 (which is now still
long ago) Intel suggested that at least three privilege levels would be
necessary to build a secure system: the innermost for memory and process
management, a middle ring for device and hardware drivers and the
outermost one for user space programs. According to my knowledge and to
what is public none of the operating system developers have followed
these precautions until today (Xen is a different case as it uses three
rings but not in the way as described above; actually it would need to
make use of all four rings provided by the protected mode interface to
be secure in theory - Nonetheless just believe me that things are not as
theoretical in practice as this description may make you believe.).
Regards,
Elmar
On 29.11.2015 22:05, Patrick Schleizer wrote:
Elmar Stellnberger:
If you wanna ask me for my security solution it is qemu based and puts
the most vulnerable system components like browsers and email programs
into a virtual machine namely qemu which is maintained by the Open
Source commnunity.
Sounds like Qubes.
Cheers,
Patrick