4 ms·

Thank you. That protection for windows scheme sounds secure, but far too complicated . >>They fall short when attackers start aiming for the hypervisor, firmw

by petra 11y ago

Thank you. That protection for windows scheme sounds secure, but far too complicated . >>They fall short when attackers start aiming for the hypervisor, firmware, etc or can do damage within the compromised VM/partition (app-layer attack) First, i think Qubes added some isolation for USB and graphics , and in general protections against firmware attacks(if you enable VT-d in bios) . Also , How much of a problem is that if you don't care about protection from state level attackers only commercial attacks, and use app layers wisely(banking has it's own layer, for ex.) ? Because i don't understand how targeted vs un-targeted applies to state vs commercial.

nickpsecurity 11y ago
"That protection for windows scheme sounds secure, but far too complicated ." We used to train laypeople to do it and even use NoScript with pre-defined profiles. Hard parts could be automated, even sold commercially. "First, i think Qubes added some isolation for USB and graphics , and in general protections against firmware attacks(if you enable VT-d in bios) ." Probably. That could contain some issues. I remember when I first evaluated it that she didn't know user-mode drivers had benefit, thought Mac OS X was an example of a microkernel, hadn't considered a trusted path, and disagreed with me about Xen being likely insecure. Now, it has a UI/graphics subsystem or something plus she was criticizing Xen on mailing list for insecurity. Lol... For these reasons, I avoided it for strong attackers as I'm not sure they're qualified on defense as much as offense. A common problem. Still probably good for containing ordinary malware, though. I plan to re-assess it for that in the near future as I heard usability is good. "Also , How much of a problem is that if you don't care about protection from state level attackers only commercial attacks" The problem is that they're the same: nation states just have more 0-days and toolkits affecting more places. All of them hit OS's and app level. So, a kernel-level 0-day is a problem there whether it's nation state or not. More are hitting firmware and routers. Hard to say what the difference is in risk level today or near future. For most, their security comes from the fact that nobody is targeting them specifically. If you're not being targeted, just using obscure stuff that has basic protection or QA can stop the wide nets. If your targeted, you want less code in trusted computing base (eg privileged) and good architecture. Currently, the only OSS project implementing a sound architecture, trusted path, microkernels, etc is GenodeOS. They got started in CompSci research leveraging proven techniques and components in defense. Their architecture itself needs more peer review as novel stuff often has trouble. Regardless, they're at alpha-stage for desktop usage and improving steadily. People just protecting their businesses should just use a hardened Mac, BSD, or Linux setup with regular backups. Optionally, if they can use it, NoScript or an ad blocker. Add HTTPSeverywhere. That will stop vast majority of attacks that would take over their system while being pretty easy to use. At least until this gets popular or a black hat group has a beef with one. ;)
- akavel 11y ago
  Thanks for this comment! I was curious recently for some "layprogrammer" info on differences between Qubes and GenodeOS; although this is not a full blown article, I find it interesting and valuable (and only the second bit of such info I stumbled upon yet; from the first one I gathered that GenodeOS has a microkernel architecture, while Qubes does not [although I'm not quite sure what it does have instead]). You wouldn't be planning to write some quick note on that topic, would you? :) edit: given that from what I managed to understand from the high-level public information till now, both of the projects: - seem to have kinda similar goals/aims (VM-like separation between applications/application domains/groups); - seem to employ a similar GUI concept of visual differentiation of apps running in different "virtual domains"; - seem to mention some established hypervisor/VM technologies, like Xen/KVM/...
  - nickpsecurity 11y ago
    Eh, I don't know about "layprogrammer" but I think laypeople can follow at least key principles with right source material. Especially programmers. Here's the differences I put in my original critique to Joanna about Qubes' design choices. The Xen project stemmed from the Nemesis OS: https://en.wikipedia.org/wiki/Nemesis_%28operating_system%29 https://en.wikipedia.org/wiki/Nemesis_%28operating_system%29 The architecture was designed for efficiency and management goals. The Xen project became a virtualization system that used a chunk of Linux in Dom0 for drivers, put guests in other VM's, and had plumbing to let them work together. IPC & VM launching had horrid performance. Kernel was complex. A nice architecture for virtualization that did improve over time in many ways. Unfortunately, you have to trust significant components like Dom0 and Xen that weren't designed for high-security. The complexity of Xen alone gave difficulty for the only team I know that tried to increase its assurance directly: http://www-archive.xenproject.org/files/xensummitboston08/XenSummitSpring08.pdf http://www-archive.xenproject.org/files/xensummitboston08/Xe... So, Qubes built on that foundation. That was my primary gripe with it as this probably wouldn't reach either assurance or performance (esp IPC) of microkernels. Otherwise, they did add a lot of good usability features and isolated some pieces. That was good. The category I place it in is a cross between a MILS and CMW system whose attack surface is in the middle. To help you understand that, I'll give an old paper on CMW's that shows what they looked like and one describing MILS architecture (i.e. separation kernels). http://web.ornl.gov/~jar/doecmw.pdf http://web.ornl.gov/~jar/doecmw.pdf http://www.omg.org/news/meetings/workshops/RT_2004_Manual/00-T2_Beckwith_etal.pdf http://www.omg.org/news/meetings/workshops/RT_2004_Manual/00... Note: Argus PitBull is a commercial example of CMW still around. MILS was implemented by Green Hills, Lynx, & VxWorks by 2005-2006. All still around if you choose to Google them. So, MILS desktops were built like the Orange Book systems to be certified at EAL6 or EAL7. That required a ridiculous amount of security activity. See pg 8 and 12-14 here... http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A-retrospective-on-the-VAX-VMM-security-kernel.pdf http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... ...plus Section 6 and 7 on p 125 here... http://aesec.com/eval/NCSC-FER-94-008.pdf http://aesec.com/eval/NCSC-FER-94-008.pdf ...to see what kind of assurance went into security kernels from prior times. Went all out with MAC, integrity levels, segments, object-based protection, covert channel analysis, generation on-site, config management. Lots of stuff to counter all threats, including malicious insiders. Current certs require even more on assurance side although HW-assists can be weaker. That's why only a handful make the cut & usually cost $$$. ;) Hope you see why my baseline was MILS-style separation kernels rather than Xen or whatever. So, what is similar in OSS world? Nizza Architecture (2004 onward) https://os.inf.tu-dresden.de/papers_ps/nizza.pdf https://os.inf.tu-dresden.de/papers_ps/nizza.pdf Perseus Architecture http://www.perseus-os.org/content/pages/Hypervisor.htm http://www.perseus-os.org/content/pages/Hypervisor.htm Note: Closer to Xen models but with Nizza- or MILS-style design attributes. This was implemented as Turaya Security Kernel & Turaya Desktop. It may be used in Sirrix TrustedDesktop but not sure. Genode Architecture draws from Nizza etc at Dresden http://www.slideshare.net/sartakov/genode-architecture http://www.slideshare.net/sartakov/genode-architecture Note: Different enough from traditional that I'd love to see formal analysis of their model by external parties. Could be issues there. However, they keep to ease modelling of overall thing and using where possible components designed specifically for secure operation. That's rare in OSS projects. Muen Separation Kernel http://muen.sk/ http://muen.sk/ Note: Fiasco.OC and seL4 are others. I know this one has been ported into GenodeOS, though. So, I hope those links paint an overall picture for you. Security of a solution against strong attackers depends on the underlying foundation. Is it trustworthy on its own? Does the use of it facilitate easy or difficult security? Historically, the security kernels and capability systems did really well on making secure operation, at least containment, be easier to pull off. UNIX-like and monolithic architectures made it horribly difficult with several attempts at secure, compatible UNIX failing. Xen itself borrows some principles from more robust systems but wasn't and still isn't designed like security kernels. It also doesn't integrate much out of high-security research although some researchers still add improvements. Qubes builds on it & will inherit some of its risks. GenodeOS is designed a bit more like security/separation kernels. It does borrow plenty from high-security research, including underlying kernels. So, although actual assurance varies, architectures like GenodeOS building on high-assurance components have much higher potential for eventual security than architectures like QubesOS building on low-to-medium-assurance platforms. And this isn't even counting the number of application-layer issues that show up within a partition. The MILS, OKL4 CAMKES, GenodeOS, etc methods of splitting applications between partitions w/ protected communications is very important for that use case. E language is a good example on capability-security side. Gotta protect trusted part or secrets from untrusted part (esp transport or UI). Mandatory access controls or CMW-style features within the partition can also help but they're fighting weaker attackers. So, these are overall the kinds of things I think about when evaluating platforms like this. Pro tip: look at underlying platform, design principles, security architecture, and assurance activities first. If these fail, then what depends on them fails. Most security-oriented tech builds on foundations of quicksand. Things built that way typically sink under weight of strong attacks. EDIT: I just noticed your edit after doing this research and write-up. Fortunately, I think it still addresses it. Talk about preemption. :)

by petra 11y ago

nickpsecurity 11y ago

"That protection for windows scheme sounds secure, but far too complicated ." We used to train laypeople to do it and even use NoScript with pre-defined profiles. Hard parts could be automated, even sold commercially. "First, i think Qubes added some isolation for USB and graphics , and in general protections against firmware attacks(if you enable VT-d in bios) ." Probably. That could contain some issues. I remember when I first evaluated it that she didn't know user-mode drivers had benefit, thought Mac OS X was an example of a microkernel, hadn't considered a trusted path, and disagreed with me about Xen being likely insecure. Now, it has a UI/graphics subsystem or something plus she was criticizing Xen on mailing list for insecurity. Lol... For these reasons, I avoided it for strong attackers as I'm not sure they're qualified on defense as much as offense. A common problem. Still probably good for containing ordinary malware, though. I plan to re-assess it for that in the near future as I heard usability is good. "Also , How much of a problem is that if you don't care about protection from state level attackers only commercial attacks" The problem is that they're the same: nation states just have more 0-days and toolkits affecting more places. All of them hit OS's and app level. So, a kernel-level 0-day is a problem there whether it's nation state or not. More are hitting firmware and routers. Hard to say what the difference is in risk level today or near future. For most, their security comes from the fact that nobody is targeting them specifically. If you're not being targeted, just using obscure stuff that has basic protection or QA can stop the wide nets. If your targeted, you want less code in trusted computing base (eg privileged) and good architecture. Currently, the only OSS project implementing a sound architecture, trusted path, microkernels, etc is GenodeOS. They got started in CompSci research leveraging proven techniques and components in defense. Their architecture itself needs more peer review as novel stuff often has trouble. Regardless, they're at alpha-stage for desktop usage and improving steadily. People just protecting their businesses should just use a hardened Mac, BSD, or Linux setup with regular backups. Optionally, if they can use it, NoScript or an ad blocker. Add HTTPSeverywhere. That will stop vast majority of attacks that would take over their system while being pretty easy to use. At least until this gets popular or a black hat group has a beef with one. ;)

akavel 11y ago
Thanks for this comment! I was curious recently for some "layprogrammer" info on differences between Qubes and GenodeOS; although this is not a full blown article, I find it interesting and valuable (and only the second bit of such info I stumbled upon yet; from the first one I gathered that GenodeOS has a microkernel architecture, while Qubes does not [although I'm not quite sure what it does have instead]). You wouldn't be planning to write some quick note on that topic, would you? :) edit: given that from what I managed to understand from the high-level public information till now, both of the projects: - seem to have kinda similar goals/aims (VM-like separation between applications/application domains/groups); - seem to employ a similar GUI concept of visual differentiation of apps running in different "virtual domains"; - seem to mention some established hypervisor/VM technologies, like Xen/KVM/...
- nickpsecurity 11y ago
  Eh, I don't know about "layprogrammer" but I think laypeople can follow at least key principles with right source material. Especially programmers. Here's the differences I put in my original critique to Joanna about Qubes' design choices. The Xen project stemmed from the Nemesis OS: https://en.wikipedia.org/wiki/Nemesis_%28operating_system%29 https://en.wikipedia.org/wiki/Nemesis_%28operating_system%29 The architecture was designed for efficiency and management goals. The Xen project became a virtualization system that used a chunk of Linux in Dom0 for drivers, put guests in other VM's, and had plumbing to let them work together. IPC & VM launching had horrid performance. Kernel was complex. A nice architecture for virtualization that did improve over time in many ways. Unfortunately, you have to trust significant components like Dom0 and Xen that weren't designed for high-security. The complexity of Xen alone gave difficulty for the only team I know that tried to increase its assurance directly: http://www-archive.xenproject.org/files/xensummitboston08/XenSummitSpring08.pdf http://www-archive.xenproject.org/files/xensummitboston08/Xe... So, Qubes built on that foundation. That was my primary gripe with it as this probably wouldn't reach either assurance or performance (esp IPC) of microkernels. Otherwise, they did add a lot of good usability features and isolated some pieces. That was good. The category I place it in is a cross between a MILS and CMW system whose attack surface is in the middle. To help you understand that, I'll give an old paper on CMW's that shows what they looked like and one describing MILS architecture (i.e. separation kernels). http://web.ornl.gov/~jar/doecmw.pdf http://web.ornl.gov/~jar/doecmw.pdf http://www.omg.org/news/meetings/workshops/RT_2004_Manual/00-T2_Beckwith_etal.pdf http://www.omg.org/news/meetings/workshops/RT_2004_Manual/00... Note: Argus PitBull is a commercial example of CMW still around. MILS was implemented by Green Hills, Lynx, & VxWorks by 2005-2006. All still around if you choose to Google them. So, MILS desktops were built like the Orange Book systems to be certified at EAL6 or EAL7. That required a ridiculous amount of security activity. See pg 8 and 12-14 here... http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A-retrospective-on-the-VAX-VMM-security-kernel.pdf http://lukemuehlhauser.com/wp-content/uploads/Karger-et-al-A... ...plus Section 6 and 7 on p 125 here... http://aesec.com/eval/NCSC-FER-94-008.pdf http://aesec.com/eval/NCSC-FER-94-008.pdf ...to see what kind of assurance went into security kernels from prior times. Went all out with MAC, integrity levels, segments, object-based protection, covert channel analysis, generation on-site, config management. Lots of stuff to counter all threats, including malicious insiders. Current certs require even more on assurance side although HW-assists can be weaker. That's why only a handful make the cut & usually cost $$$. ;) Hope you see why my baseline was MILS-style separation kernels rather than Xen or whatever. So, what is similar in OSS world? Nizza Architecture (2004 onward) https://os.inf.tu-dresden.de/papers_ps/nizza.pdf https://os.inf.tu-dresden.de/papers_ps/nizza.pdf Perseus Architecture http://www.perseus-os.org/content/pages/Hypervisor.htm http://www.perseus-os.org/content/pages/Hypervisor.htm Note: Closer to Xen models but with Nizza- or MILS-style design attributes. This was implemented as Turaya Security Kernel & Turaya Desktop. It may be used in Sirrix TrustedDesktop but not sure. Genode Architecture draws from Nizza etc at Dresden http://www.slideshare.net/sartakov/genode-architecture http://www.slideshare.net/sartakov/genode-architecture Note: Different enough from traditional that I'd love to see formal analysis of their model by external parties. Could be issues there. However, they keep to ease modelling of overall thing and using where possible components designed specifically for secure operation. That's rare in OSS projects. Muen Separation Kernel http://muen.sk/ http://muen.sk/ Note: Fiasco.OC and seL4 are others. I know this one has been ported into GenodeOS, though. So, I hope those links paint an overall picture for you. Security of a solution against strong attackers depends on the underlying foundation. Is it trustworthy on its own? Does the use of it facilitate easy or difficult security? Historically, the security kernels and capability systems did really well on making secure operation, at least containment, be easier to pull off. UNIX-like and monolithic architectures made it horribly difficult with several attempts at secure, compatible UNIX failing. Xen itself borrows some principles from more robust systems but wasn't and still isn't designed like security kernels. It also doesn't integrate much out of high-security research although some researchers still add improvements. Qubes builds on it & will inherit some of its risks. GenodeOS is designed a bit more like security/separation kernels. It does borrow plenty from high-security research, including underlying kernels. So, although actual assurance varies, architectures like GenodeOS building on high-assurance components have much higher potential for eventual security than architectures like QubesOS building on low-to-medium-assurance platforms. And this isn't even counting the number of application-layer issues that show up within a partition. The MILS, OKL4 CAMKES, GenodeOS, etc methods of splitting applications between partitions w/ protected communications is very important for that use case. E language is a good example on capability-security side. Gotta protect trusted part or secrets from untrusted part (esp transport or UI). Mandatory access controls or CMW-style features within the partition can also help but they're fighting weaker attackers. So, these are overall the kinds of things I think about when evaluating platforms like this. Pro tip: look at underlying platform, design principles, security architecture, and assurance activities first. If these fail, then what depends on them fails. Most security-oriented tech builds on foundations of quicksand. Things built that way typically sink under weight of strong attacks. EDIT: I just noticed your edit after doing this research and write-up. Fortunately, I think it still addresses it. Talk about preemption. :)