3 ms·

Qubes OS¹, the only reliable OS of our time. See also "The Linux Security Circus: On GUI Isolation (2011)" by Joanna Rutkowska². ¹ https://www.qubes-os.org/ h

Qubes OS¹, the only reliable OS of our time. See also "The Linux Security Circus: On GUI Isolation (2011)" by Joanna Rutkowska². ¹ https://www.qubes-os.org/ https://www.qubes-os.org/ ² https://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html https://theinvisiblethings.blogspot.de/2011/04/linux-securit..., via https://news.ycombinator.com/item?id=11229517 https://news.ycombinator.com/item?id=11229517

milcron 10y ago
I prefer OpenBSD to Qubes. Over the past couple years, my approach has changed from blacklisting what’s broken, to whitelisting what’s safe. NoScript in the browser, and I’m working on installing OpenBSD on my Libreboot laptop (tricky because UEFI support is so new). OpenBSD has my favorite approach. Continual auditing of the codebase, and they’re always implementing new 'seatbelts', such as ASLR, W^X, and now pledge(2). These seatbelts are used liberally – even in programs that you theoretically shouldn’t need protection from, such as the system-provided implementation of cat. They aggressively delete dead code, and probably have the smallest codebase of all modern nix systems. The best code is no code. :) Theo has some great comments on magical “silver-bullet” thinking about security. In this case, specifically about the security of VMs (2007, so pretty dated now): x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. Harsh, but not inaccurate. And it’s part of the reason I’d rather use OpenBSD than QubesOS. Eight years after that comment, a critical vulnerability in Xen affected the security of QubesOS, and the developers were shocked, shocked! It is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again (assert-like mechanisms perhaps?). Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work. http://arstechnica.com/security/2015/10/xen-patches-7-year-old-bug-that-shattered-hypervisor-security/ http://arstechnica.com/security/2015/10/xen-patches-7-year-o...
- dandelion_lover 10y ago
  Thank you for a comprehensive answer. I do not think that one vulnerability in 8+ years proofs insecurity of QubesOS (by the way, it was found by their developers). OpenBSD is not free from kernel vulnerabilities on such a long time scale. Security through correctness never works, because people are not ideal. (Xen developers are also trying to decrease the code base and make sure the code is as correct as possible.) The only "silver bullet" is defense in depth [0], i.e., trying everything you can. I heard [1] that OpenBSD is concentrated on the security of the kernel too much, ignoring the isolation of applications. However, most frequently, attacks come through applications. And this is exactly the point of QubesOS: to isolate the applications as much as possible. You might also be interested in a comparison between different approaches to security [2]. [0] https://en.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.wikipedia.org/wiki/Defense_in_depth_(computing) [1] https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ https://allthatiswrong.wordpress.com/2010/01/20/the-insecuri... [2] https://theinvisiblethings.blogspot.de/2008/09/three-approaches-to-computer-security.html https://theinvisiblethings.blogspot.de/2008/09/three-approac...
  - milcron 10y ago
    Great links, thanks! Defense in depth is a good strategy, and it's definitely good to see QubesOS doing their thing. I'm glad to see activity in the secure computing space regardless of which OS is the most secure. Since the focus of the thread is reliability, I'd like to point out one common criticism of OpenBSD (such as in your link [1]), which is that they aren't actually focused on security as they are on writing correct, quality code. ...Is that actually a downside? I like correct, quality code. And if that approach happened to get them 90% of the way to a secure system, that's just a cherry on top. What I like most about OpenBSD is how starkly simple it is. Yes, technologies lag behind somewhat - they just got support for EFI and 802.11n - but in OpenBSD something either works or it doesn't. Nothing in the base system is obviously busted. A native OpenBSD hypervisor[0] is finally in the works, so in the future it might be possible to build a Qubes-like thing on top. [0] "OpenBSD vmm/vmd Update" http://bhyvecon.org/bhyvecon2016-Mike.pdf http://bhyvecon.org/bhyvecon2016-Mike.pdf

milcron 10y ago

I prefer OpenBSD to Qubes. Over the past couple years, my approach has changed from blacklisting what’s broken, to whitelisting what’s safe. NoScript in the browser, and I’m working on installing OpenBSD on my Libreboot laptop (tricky because UEFI support is so new). OpenBSD has my favorite approach. Continual auditing of the codebase, and they’re always implementing new 'seatbelts', such as ASLR, W^X, and now pledge(2). These seatbelts are used liberally – even in programs that you theoretically shouldn’t need protection from, such as the system-provided implementation of cat. They aggressively delete dead code, and probably have the smallest codebase of all modern nix systems. The best code is no code. :) Theo has some great comments on magical “silver-bullet” thinking about security. In this case, specifically about the security of VMs (2007, so pretty dated now): x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. Harsh, but not inaccurate. And it’s part of the reason I’d rather use OpenBSD than QubesOS. Eight years after that comment, a critical vulnerability in Xen affected the security of QubesOS, and the developers were shocked, shocked! It is really shocking that such a bug has been lurking in the core of the hypervisor for so many years. In our opinion the Xen project should rethink their coding guidelines and try to come up with practices and perhaps additional mechanisms that would not let similar flaws to plague the hypervisor ever again (assert-like mechanisms perhaps?). Otherwise the whole project makes no sense, at least to those who would like to use Xen for security-sensitive work. http://arstechnica.com/security/2015/10/xen-patches-7-year-old-bug-that-shattered-hypervisor-security/ http://arstechnica.com/security/2015/10/xen-patches-7-year-o...

dandelion_lover 10y ago
Thank you for a comprehensive answer. I do not think that one vulnerability in 8+ years proofs insecurity of QubesOS (by the way, it was found by their developers). OpenBSD is not free from kernel vulnerabilities on such a long time scale. Security through correctness never works, because people are not ideal. (Xen developers are also trying to decrease the code base and make sure the code is as correct as possible.) The only "silver bullet" is defense in depth [0], i.e., trying everything you can. I heard [1] that OpenBSD is concentrated on the security of the kernel too much, ignoring the isolation of applications. However, most frequently, attacks come through applications. And this is exactly the point of QubesOS: to isolate the applications as much as possible. You might also be interested in a comparison between different approaches to security [2]. [0] https://en.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.wikipedia.org/wiki/Defense_in_depth_(computing) [1] https://allthatiswrong.wordpress.com/2010/01/20/the-insecurity-of-openbsd/ https://allthatiswrong.wordpress.com/2010/01/20/the-insecuri... [2] https://theinvisiblethings.blogspot.de/2008/09/three-approaches-to-computer-security.html https://theinvisiblethings.blogspot.de/2008/09/three-approac...
- milcron 10y ago
  Great links, thanks! Defense in depth is a good strategy, and it's definitely good to see QubesOS doing their thing. I'm glad to see activity in the secure computing space regardless of which OS is the most secure. Since the focus of the thread is reliability, I'd like to point out one common criticism of OpenBSD (such as in your link [1]), which is that they aren't actually focused on security as they are on writing correct, quality code. ...Is that actually a downside? I like correct, quality code. And if that approach happened to get them 90% of the way to a secure system, that's just a cherry on top. What I like most about OpenBSD is how starkly simple it is. Yes, technologies lag behind somewhat - they just got support for EFI and 802.11n - but in OpenBSD something either works or it doesn't. Nothing in the base system is obviously busted. A native OpenBSD hypervisor[0] is finally in the works, so in the future it might be possible to build a Qubes-like thing on top. [0] "OpenBSD vmm/vmd Update" http://bhyvecon.org/bhyvecon2016-Mike.pdf http://bhyvecon.org/bhyvecon2016-Mike.pdf