brl

Joined 19 years ago

Karma

1,178

Submissions

395

Member since

Sep 19

View on Hacker News

Recent submissions

Comment · 9 years ago

Why would anybody censor the viewpoint of a woman scientist in this particular debate? How much cognitive dissonance is too much?

Comment · 9 years ago

> I would love to hear his side of the story.

Some of his side of the story has been told in the leaked emails:

https://www.hdevalence.ca/etc/34de2f3c2a48f7da/EmAiLs.txt

Comment · 10 years ago

I'm answering a comment chain about how Subgraph OS does not 'isolate' the network or USB stacks which is frequently brought up as an important deficiency in comparison to Qubes OS. My point is that this isn't a significant advantage of Qubes because such attacks are rare and difficult, and because they're even harder to perform against Subgraph OS.

I wasn't talking about AppVMs at all, but you can of course persistently backdoor Qubes AppVMs in numerous ways by writing to the user home directory. In Subgraph OS we design our application sandboxes to prevent exactly this.

Comment · 10 years ago

> I don't think there are any amnesic features like in Tails nor strong isolation between gateway and workstation to prevent IP leaks like in Whonix.

Subgraph sandboxes run in a network namespace with no direct access to the network or ability to view any of the physical network interfaces on the system. There is no way for an attacker to send network traffic directly or to discover the real IP address of the system without breaking out of the sandbox.

Comment · 10 years ago

I'm from Subgraph and I disagree.

On Qubes OS the networking VM runs a standard Linux kernel with no special security hardening at all apart from the simple fact that it runs in a separate Xen VM. If an attacker is able to compromise NetVM, they may not have direct access to user data, but they have dangerous access to perform further attacks:

  - Attacks against hypervisor to break isolation
  - Side channel attacks against other Qubes VMs to steal cryptographic keys
  - Interception and tampering with networking traffic
  - Attacks against any internal network this Qubes OS computer connects to.

So if you assume that remote attacks against the Linux kernel networking stack are an important threat, the consequences of a successful attack even against Qubes are pretty bad.

Subgraph OS hardens the Linux kernel with grsecurity, which includes many defenses against exploitation which have historically prevented local exploitation of most security vulnerabilities against the kernel. Exploiting kernel vulnerabilities locally is so much easier, probably never less than an order of magnitude easier. It's so rare to reliably exploit kernel vulnerabilities remotely even against an unhardened kernel that teams present papers at top security conferences about a single exploit:

https://www.blackhat.com/presentations/bh-usa-07/Ortega/Whit...

I know it's contentious to say so, but I don't believe that anybody will ever remotely exploit a kernel vulnerability against a grsecurity hardened Linux kernel, especially since RAP was introduced:

https://grsecurity.net/rap_announce.php

The threat of remotely attacking the Linux kernel through the networking or USB stack was always low in my opinion, but as the threat approaches zero it raises some questions about how justifiable the system VMs are in Qubes OS considering the system complexity and usability impairment they introduce.

Comment · 10 years ago

> imho the qubes approach is more viable and exposes far less attack surface.

I don't know what you base that opinion on since it's not an easy comparison to reason about. One metric you could use would be actual vulnerabilities. In the last year there have been several hypervisor escape vulnerabilites that compromised Qubes OS VM isolation completely, most (all?) of which have been present in Xen for the entire lifetime of the Qubes project.

By contrast during the same period only one Linux kernel vulnerability (DirtyCow) affected Subgraph sandboxed applications, and it would only have been exploitable using techniques which have not been disclosed in any public exploit so far.

Comment · 10 years ago