Re: Mandatory Access Control
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
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 >> >
Re: Mandatory Access Control
Dear Henriette, Yes, I am using qemu-kvm based virtualization. According to my experience that was sufficient to protect the host from the guest. The most vulnerable part will be the graphics output as I have already said. Nonetheless I did also receive the many messages about vulnerabilities in the Wifi stack. Gonna have to tell that I do only have practical experience with qemu-kvm/ethernet. You can use a mobile wifi router through which you plug in your ethernet port (or wait for and trust in the fixes). Separating the Wifi driver in its own Xen-domain would of course be another solution as long as all graphcis output still becomes filtered by emulating a virtual graphics card/device. Best Elmar On 29.11.2015 22:31, Henriette wrote: Hey Elmar, I was looking into using virtualization for security purposes too. However I refrained from using a full grown vbox installation so far. I saw that qemu provides a user-mode virtualization. I could imagine that this brings already some security if you are able to specify access only to certain directories etc. However I couldn't find any info with some quick google searches on how to use qemu to improve systems security by virt. Are you using this mode to get some security or is there no way around a full virtualization to improve security? Best Henriette Am Sun, 29 Nov 2015 21:26:41 +0100 schrieb Elmar Stellnberger <estel...@gmail.com>: SELinux is more elaborate and more complicated than Apparmor; tomoyo relatively new. I would personally regard none of those MAC systems as ultimate remedy to hard security problems. In 2011 I had a RedHat/SELinux system in its default configuration and it was compromised within minutes by simply viewing the page of my bank with a web browser (read the whole at: http://www.elstel.org/Censorship.html.en). Note that a single faulty system call in the Linux kernel may be used to obtain root rights leaving all additional security gains that MAC systems should deliver behind. Please note also that a system can not be secured without securing your X-server (formerly one could even paste text into any other window like a root console without being in need of root rights). Finally the security profiles of MAC systems are very complicated so that they would hardly deliver the security as possible in theory. 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. Regards, Elmar On 29.11.2015 18:29, c4p0 wrote: I read the fucking manuals but don't have clear what is the better option of "Mandatory Access Control" for debian jessie. (AppArmor, SElinux, tomoyo, etc ..) someone can give me your opinion about it? thanks in advance
Re: Mandatory Access Control
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
Re: Mandatory Access Control
Elmar, Do you have documentation of your labours available? Sincerely, Joh On Monday 30 November 2015 18:20:00 Elmar Stellnberger wrote: > Dear Henriette, > > Yes, I am using qemu-kvm based virtualization. According to my > experience that was sufficient to protect the host from the guest. The > most vulnerable part will be the graphics output as I have already said. > Nonetheless I did also receive the many messages about vulnerabilities > in the Wifi stack. Gonna have to tell that I do only have practical > experience with qemu-kvm/ethernet. You can use a mobile wifi router > through which you plug in your ethernet port (or wait for and trust in > the fixes). Separating the Wifi driver in its own Xen-domain would of > course be another solution as long as all graphcis output still becomes > filtered by emulating a virtual graphics card/device. > > Best Elmar > > On 29.11.2015 22:31, Henriette wrote: > > Hey Elmar, > > > > I was looking into using virtualization for security purposes too. However > > I refrained from using a full grown vbox installation so far. > > > > I saw that qemu provides a user-mode virtualization. I could imagine that > > this brings already some security if you are able to specify access only > > to certain directories etc. However I couldn't find any info with some > > quick google searches on how to use qemu to improve systems security by > > virt. Are you using this mode to get some security or is there no way > > around a full virtualization to improve security? > > > > Best Henriette > > > > Am Sun, 29 Nov 2015 21:26:41 +0100 > > > > schrieb Elmar Stellnberger <estel...@gmail.com>: > >> SELinux is more elaborate and more complicated than Apparmor; tomoyo > >> relatively new. I would personally regard none of those MAC systems as > >> ultimate remedy to hard security problems. In 2011 I had a > >> RedHat/SELinux system in its default configuration and it was > >> compromised within minutes by simply viewing the page of my bank with a > >> web browser (read the whole at: > >> http://www.elstel.org/Censorship.html.en). Note that a single faulty > >> system call in the Linux kernel may be used to obtain root rights > >> leaving all additional security gains that MAC systems should deliver > >> behind. Please note also that a system can not be secured without > >> securing your X-server (formerly one could even paste text into any > >> other window like a root console without being in need of root rights). > >> Finally the security profiles of MAC systems are very complicated so > >> that they would hardly deliver the security as possible in theory. 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. > >> > >> Regards, > >> Elmar > >> > >> On 29.11.2015 18:29, c4p0 wrote: > >>> I read the fucking manuals but don't have clear what is the better > >>> option of "Mandatory Access Control" for debian jessie. > >>> (AppArmor, SElinux, tomoyo, etc ..) > >>> > >>> someone can give me your opinion about it? > >>> thanks in advance
Re: Mandatory Access Control
I think the problem lies in this "someone can give me your opinion about it?" It's really all opinion. Each have their advantages and disadvantages. Pretty sure most companies that would require SElinux would also require RHEL/CentOS. Debian simply gives you a choice of what you'd prefer. So if you really want to do it, look at each of them, and decide for yourself. On Sun, 2015-11-29 at 14:29 -0300, c4p0 wrote: > I read the fucking manuals but don't have clear what is the better > option of "Mandatory Access Control" for debian jessie. > (AppArmor, SElinux, tomoyo, etc ..) > > someone can give me your opinion about it? > thanks in advance > >
Re: Mandatory Access Control
SELinux is more elaborate and more complicated than Apparmor; tomoyo relatively new. I would personally regard none of those MAC systems as ultimate remedy to hard security problems. In 2011 I had a RedHat/SELinux system in its default configuration and it was compromised within minutes by simply viewing the page of my bank with a web browser (read the whole at: http://www.elstel.org/Censorship.html.en). Note that a single faulty system call in the Linux kernel may be used to obtain root rights leaving all additional security gains that MAC systems should deliver behind. Please note also that a system can not be secured without securing your X-server (formerly one could even paste text into any other window like a root console without being in need of root rights). Finally the security profiles of MAC systems are very complicated so that they would hardly deliver the security as possible in theory. 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. Regards, Elmar On 29.11.2015 18:29, c4p0 wrote: I read the fucking manuals but don't have clear what is the better option of "Mandatory Access Control" for debian jessie. (AppArmor, SElinux, tomoyo, etc ..) someone can give me your opinion about it? thanks in advance
Mandatory Access Control
I read the fucking manuals but don't have clear what is the better option of "Mandatory Access Control" for debian jessie. (AppArmor, SElinux, tomoyo, etc ..) someone can give me your opinion about it? thanks in advance -- A5B4 7CDF 17BD E9AD 7A78 092E 53F4 DDB5 A091 CB3B signature.asc Description: OpenPGP digital signature
