←back to thread

276 points chei0aiV | 2 comments | | HN request time: 0.516s | source
Show context
kragen ◴[] No.10458647[source]
Probably worth pointing out that the author is the project lead of Qubes, one of the very few promising projects in the vast wasteland of computer security.
replies(2): >>10459513 #>>10459645 #
kachnuv_ocasek ◴[] No.10459645[source]
Very few? Seriously?
replies(4): >>10459760 #>>10459957 #>>10460536 #>>10461036 #
mtgx ◴[] No.10460536[source]
I think he means there are few operating systems out there that make security the primary goal. Most other options seem to think in terms of "how can we best secure the platform we already have and is used by millions of people without breaking anything".

When that's what you're working with, you're limiting yourself quite a bit in terms of adding new security solutions. At best you'll be at least a decade behind the innovators in security who aren't afraid to build new stuff from scratch and break the old stuff.

replies(1): >>10460576 #
1. kragen ◴[] No.10460576[source]
No, that's not what I mean, and that's not what Qubes is.

Making security the primary goal of your operating system would be nearly as perverse as making swapping the primary goal of your operating system. The primary reason security seems special here is that we do have working swapping in our operating systems, but we don't have working security.

Nevertheless, if you try to add virtual memory to an operating system that was designed without knowledge of how such a thing could work (like nearly all 1960s operating systems) it is going to be pretty rough going! Today, security is where virtual memory was 50 years ago.

Qubes is interesting especially because it doesn't break compatibility with everything else.

replies(1): >>10461294 #
2. nickpsecurity ◴[] No.10461294[source]
That's what any VMM-style solution does, though. They use basic isolation and controlled sharing while letting problems remain in every other component. Nothing special there and doesn't address many security threats that hit other parts.

I mainly consider solutions like Qubes to be for preventing accidental leaks, containing damage from regular malware, and making recovery easier. Much like the Compartmented Mode Workstations and MILS virtualization that came before it.

Real, more-thorough security will break compatibility or take a huge performance/functionality hit. Was true in any system designed to high assurance or surviving NSA pentesting. Will be more true for whatever supports legacy applications on today's more complex, leaky ISA's/API's. CheriBSD is closest thing to an exception but I don't even trust its monolithic parts due to how attacks can jump around in a system. Nizza Architecture on non-Intel, security-enhanced processors is best model for now given we can at least isolate security-critical apps into their own partitions on tiny TCB's. No mature FOSS implements that, though.

So, regular malware defence with Qubes, etc and energy-gapped systems + KVM's + guards for high-strength attacker defence remain the options.