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


Groups > linux.debian.security > #4438

Re: Mandatory Access Control

From Patrick Schleizer <adrelanos@riseup.net>
Newsgroups linux.debian.security
Subject Re: Mandatory Access Control
Date 2015-11-30 17:50 +0100
Message-ID <qAzOi-66r-15@gated-at.bofh.it> (permalink)
References (3 earlier) <qz2Uq-4s4-13@gated-at.bofh.it> <qAe78-DH-11@gated-at.bofh.it> <qAgLE-2jK-5@gated-at.bofh.it> <qAzuY-5YC-69@gated-at.bofh.it> <qAzuY-5YC-67@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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