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

Re: Mandatory Access Control



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
>>
> 


Reply to: