Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Operating System That Can Protect You Even if You Get Hacked

micahflee.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: The Operating System That Can Protect You Even if You Get Hacked

#31

Post by fzltrp »

72deluxe wrote: post #25
cyphunk wrote: post #24

If someone is wondering, Qubes (and all Linux based distros) are not Macbook friendly [1]. But honestly, if security or privacy are a priority for you then you are probably not using a Macbook anyway. [1]: https://groups.google.com/forum/#!topic/qubes-devel/uLDYGdKk...

Why would you not be using a Macbook if you want security or privacy? If you are referring to Mac OSX and its integrations with App Stores and social media systems, note that it is entirely optional (I don't use any of the social media guff bundled into the OS). Unless you are referring to something else and think that buying a piece of hardware somehow means you don't care about privacy, regardless of which software…

Personnally, I would not be speaking about Apple hardware, I don't know it well enough. But in general, hardware is relevant to security, simply because most of them nowadays contain firmwares. In some cases, that firmware can even be a small embedded OS. If that particular piece of software happens to deal with inbound data (think WiFi controller), then you have a potential security hole _which you have no control on_.

Re: The Operating System That Can Protect You Even if You Get Hacked

#32

Post by ianopolous »

I do everything these days in a VM, Virtualbox at the moment. A different VM for different classes of task. With the shared clipboard and shared folder options it is still pretty convenient. Of course, my laptop has 16gb of ram which helps if I want to run multiple VMs at once with more than a few gb each. It's nice to have a base VM for each OS I use and just branch off that for new VMs.

Re: The Operating System That Can Protect You Even if You Get Hacked

#33

Post by throwaway7767 »

zurn wrote: post #7
euank wrote: post #5

Earlier quoted context omitted.

I don't see how that follows or relates; chrome's sandboxes are definitely not VMs... VMs are in general better understood and far better isolated. Can you expound on that comment?

How is the isolation in Xen better than Chrome sandboxes - do you mean the attack surface is smaller, the code quality better, or the task somehow inherently simpler/easier? From where I sit, vulnerabilities in virtualization have seen less public scrutiny than the Chrome sandbox. Eg none of the hypervisor vendors have a bug bounty program, which would be at least some kind of signal.

The attack surface of a paravirtualized Xen VM to its hypervisor is much smaller than a linux application talking to the linux kernel.

Of course it's not perfect, but xen has a pretty good track record. And a significant chunk of the flaws that have been found xen were found by the qubes devs.

Re: The Operating System That Can Protect You Even if You Get Hacked

#34

Post by A1kmm »

dobbsbob wrote: post #3
euank wrote: post #2

Of course, the entire premise of this operating system is that VMs are secure, even though there have been exploits targeting them in the past [0]. Disabling virtualization capabilities in the bios is a semi-common recommendation for securing a computer... Still, this OS is a darn sight better than nothing and it'll certainly protect against most things. However, touting it as perfect is misleading. [0]: https://en.w…

If they can break out of Chrome sandboxes they can target Qubes

Defense in depth is a good thing, and this adds another layer.

If an attacker has to exploit the browser to get access as an unprivileged user, then find a local exploit to get root on the VM, then circumvent SELinux on the VM, then load a kernel module on the VM that exploits the hypervisor to get DOM0, then the attacker needs to burn a lot more 0-days and considerably increase their chances of getting caught compared to just exploiting the browser and going straight to accessing the information they want.

Unfortunately, some types of attacks might bypass multiple layers in one hit (e.g. exploit graphics driver on X server VM through WebGL, install keylogger on X server).

Re: The Operating System That Can Protect You Even if You Get Hacked

#35

Post by throwaway7767 »

muyuu wrote: post #23

"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." Theo de Raadt, 2007

Did anyone claim qubes does not have security holes? The point of qubes is not to "solve security", it's to make a useable everyday OS that offers better security than other general-purpose OSs. It does this by isolation and minimizing attack surfaces between moving parts.

EDIT: Here is some documentation that describes the security stance of the Qubes OS project. As you will see, being security-bug-free is not a goal, and in fact, the guiding principle is that all code has security bugs, hence everything is isolated to prevent escalation. http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf http://qubes-os.org/trac/wiki/SecurityCriticalCode

Re: The Operating System That Can Protect You Even if You Get Hacked

#36

Post by jrochkind1 »

It seems likely that this indeed will give you increased security.

But it is dangerous to educate non-technical people that this VM-based OS gives you absolute guarantees of security.

And please don't start redefining the term "air-gapped" such that it applies to a VM that doesn't have network access. "air" "gapped" is a pretty absolute concept, and does not mean a VM without network on a host that does.

Re: The Operating System That Can Protect You Even if You Get Hacked

#38

Post by kyboren »

A1kmm wrote: post #34
dobbsbob wrote: post #3

Earlier quoted context omitted.

If they can break out of Chrome sandboxes they can target Qubes

Defense in depth is a good thing, and this adds another layer. If an attacker has to exploit the browser to get access as an unprivileged user, then find a local exploit to get root on the VM, then circumvent SELinux on the VM, then load a kernel module on the VM that exploits the hypervisor to get DOM0, then the attacker needs to burn a lot more 0-days and considerably increase their chances of getting caught compar…

I've been using Qubes every day for well over a year now, and I know enough about the architecture to dispel a few of these assumptions.

1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about.

2. SELinux is disabled in AppVMs by default.

3. The GUI virtualization architecture takes this into account, and uses Xen shared memory to blindly copy a framebuffer prepared by the domU X server. Exploiting the dom0 X server should be very difficult.

Also, one main attractive feature of Qubes is the networking architecture: so long as iptables is not compromised by an attack, and there is no Xen sandbox breakout, it's fairly easy to set very restrictive or specific firewall and routing rules which will thwart many zero-day threats.

Further, VMs externally look no different than any other Fedora 18/20 installation, so even if an attacker had a Xen sandbox exploit, they would have to have specific knowledge that you run Qubes (e.g. you posted to Hacker News saying so ;)) in order to own your system, which is security 'by obscurity' but is still useful.

Qubes is more of a powerful security-enabling tool than a 'secure by default' distribution. Non-technical people (e.g. human rights lawyers, national security reporters) should probably use Tails unless they have a high degree of technical sophistication. It's very easy to shoot yourself in the foot.

Re: The Operating System That Can Protect You Even if You Get Hacked

#39

Post by kyboren »

uuid_to_string wrote: post #15

Love the comment by "z". :) The people working on this are sharp, for sure. But I will never think of VM's as a path to "security". Xen is useful for a variety of purposes (including resiliency, which can help if you are hacked), but I'll never rely on it for "security". Curious what bootloader they are using for the Xen kernels.

GRUB2, and optionally tboot for "anti evil-maid" (http://theinvisiblethings.blogspot.com/2011/09/anti-evil-mai...).

Re: The Operating System That Can Protect You Even if You Get Hacked

#40

Post by throwaway7767 »

kyboren wrote: post #38
A1kmm wrote: post #34

Earlier quoted context omitted.

Defense in depth is a good thing, and this adds another layer. If an attacker has to exploit the browser to get access as an unprivileged user, then find a local exploit to get root on the VM, then circumvent SELinux on the VM, then load a kernel module on the VM that exploits the hypervisor to get DOM0, then the attacker needs to burn a lot more 0-days and considerably increase their chances of getting caught compar…

I've been using Qubes every day for well over a year now, and I know enough about the architecture to dispel a few of these assumptions. 1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about. 2. SELinux is disabled in AppVMs by default. 3. The GUI virtualiza…

> 1. By default, there is no need for an attacker to find a local exploit to get root--the user account has unrestricted password-less sudo authorization. This is one of the things I disagree with the developers about.

I've been using qubes for a little while myself. I agree that it should be harder to go from domU user to domU root. However I think having to manage passwords for every AppVM also negates a lot of the benefits of the template setup in qubes (I currently have about 30 AppVMs).

My ideal solution to this problem, which I might implement at some point, would be to implement a PAM module for domU that asks dom0 whether escalation to root is okay. That way, dom0 can prompt the user whether to allow it or not, and no per-AppVM passwords have to be remembered.

Post reply on HN