Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #4440

Re: Mandatory Access Control

Show all headers | View raw

I know. The question here is how the Qubes clients connect to the 
Xen-GUI-dom (Concerning Windows I am just annoyed about that many 
indirect promotion for a closed source host system when it comes to 
security issues). Separating the Wifi/WLAN driver may be a good point 
though.

Elmar

P.S.: I would have nothing against a Windows guest (as you have 
suggested). However there was also some suggestion about using it as 
host in the Qubes introduction:
 > These are known as “Type 2” or “hosted” hypervisors. These programs
 > are popular because they’re designed  primarily to be easy to use and
 > run under popular OSes like Windows ...


On 30.11.2015 17:48, Patrick Schleizer wrote:
> 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
>>>
>>
>

Back to linux.debian.security | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [SECURITY] [DSA 3405-1] smokeping security update Fredrik Kers <fredrik.kers@netrounds.com> - 2015-11-26 09:40 +0100
  Re: [SECURITY] [DSA 3405-1] smokeping security update Paul Wise <pabs@debian.org> - 2015-11-26 11:30 +0100
    Re: [SECURITY] [DSA 3405-1] smokeping security update Fredrik Kers <fredrik.kers@netrounds.com> - 2015-11-26 12:30 +0100
      Mandatory Access Control c4p0 <capo@riseup.net> - 2015-11-29 18:40 +0100
        Re: Mandatory Access Control Jason Fergus <leech@thefnords.org> - 2015-11-29 21:00 +0100
        Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-29 21:30 +0100
          Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 17:30 +0100
            Re: Mandatory Access Control Patrick Schleizer <adrelanos@riseup.net> - 2015-11-30 17:50 +0100
              Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 18:50 +0100
          Re: Mandatory Access Control Elmar Stellnberger <estellnb@gmail.com> - 2015-11-30 18:30 +0100
            Re: Mandatory Access Control Johannes Graumann <johannes.graumann@graumannschaft.org> - 2015-11-30 19:00 +0100

csiph-web