4 ms·

imho the qubes approach is more viable and exposes far less attack surface. Qubes is also, contrary to it's reputation, a very usable OS (with KDE in dom0, at l

by dom0 10y ago

imho the qubes approach is more viable and exposes far less attack surface. Qubes is also, contrary to it's reputation, a very usable OS (with KDE in dom0, at least).

mad_titan 10y ago
I honestly find the XFCE desktop more usable.
- dom0 10y ago
  I greatly prefer a desktop that has searchable menus and decent Hi DPI support (although the older version in F23/Q dom0 isn't quite plugnplay). Personally I think that KDE also looks better. Especially XFCEs window decorations are just so... 90s "design".
  - armitron 10y ago
    Hello Joanna.
    - mtgx 10y ago
      Joanna hates KDE. https://github.com/QubesOS/qubes-issues/issues/2119 https://github.com/QubesOS/qubes-issues/issues/2119
brl 10y 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.
xdma 10y ago
Subgraph does lots of things Qubes doesn't, and this will only increase over time. For example: an experimental Subgraph OS feature[1] is to, by mandatory sandbox policy, prevent a specific application from connecting to anything except TLS endpoints, or specific TLS endpoints while adding certificate pinning outside of an application and performing extra-app validation. Could be useful over Tor or public wi-fi, right? Qubes is not going to build this, yet I am running a prototype of it on my SGOS dev laptop. You can compare the sandbox technologies: hypervisor vs. Linux kernel containment facilities, but we are doing a lot more than that. There's no doubt that there will be many that want to run Subgraph or parts of Subgraph inside of Qubes for this reason, though we believe Qubes needs strong exploit mitigation throughout, in every VM, and I think wouldn't recommend it until that is the default. 1. Screenshots of Oz' coming TLS Guard, which proxies the TLS handshake to ensure correct TLS session & enforce other policy req's: https://twitter.com/attractr/status/783013051335319553 https://twitter.com/attractr/status/783013051335319553 https://twitter.com/attractr/status/783521883715203073 https://twitter.com/attractr/status/783521883715203073 https://twitter.com/attractr/status/786235879111090176 https://twitter.com/attractr/status/786235879111090176 etc (edited, formatting)
- nickpsecurity 10y ago
  " Qubes is not going to build this, yet I am running a prototype of it on my SGOS dev laptop." You can do that in Qubes or the architecturally-superior GenodeOS. Genode is FOSS so nothing stops you. Any programs computing with secrets can run in an isolated partition to prevent leaks. Similar with protecting integrity of backups like in some partitioned filesystems. And you get the benefits of subgraph on the inside.
  - xdma 10y ago
    No, Qubes hasn't written the TLS client handshake proxy to enforce the policy. Out of scope. That's what I meant, and it's just one example of the things above the level of "Qubes" or "Oz" plumbing that makes Subgraph OS what it is.
  - saganus 10y ago
    Sorry for being OT but do you mind explaining a bit what exactly does Genode do/is? I read about it in their web page but I'm not sure I understand the difference between "an OS" and "an OS framework". It seems that they are trying to create an architecture with all components compartmentalized, but it says it can run Linux and Windows so I'm guessing it's virtualizing something at some point. Also, they say they have a reference implementation of the architecture, so I guess the real work is defining that architecture and making an API compatible with what modern OS's do so later on they can jump on board and make it Genode compatible? It sounds very interesting but it feels like I'm misunderstanding a lot and thus hitting a wall here due to lack of knowledge so any pointers are appreciated :)

by dom0 10y ago

imho the qubes approach is more viable and exposes far less attack surface. Qubes is also, contrary to it's reputation, a very usable OS (with KDE in dom0, at least).

mad_titan 10y ago

I honestly find the XFCE desktop more usable.

dom0 10y ago
I greatly prefer a desktop that has searchable menus and decent Hi DPI support (although the older version in F23/Q dom0 isn't quite plugnplay). Personally I think that KDE also looks better. Especially XFCEs window decorations are just so... 90s "design".
- armitron 10y ago
  Hello Joanna.
  - mtgx 10y ago
    Joanna hates KDE. https://github.com/QubesOS/qubes-issues/issues/2119 https://github.com/QubesOS/qubes-issues/issues/2119

brl 10y 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.

xdma 10y ago

Subgraph does lots of things Qubes doesn't, and this will only increase over time. For example: an experimental Subgraph OS feature[1] is to, by mandatory sandbox policy, prevent a specific application from connecting to anything except TLS endpoints, or specific TLS endpoints while adding certificate pinning outside of an application and performing extra-app validation. Could be useful over Tor or public wi-fi, right? Qubes is not going to build this, yet I am running a prototype of it on my SGOS dev laptop. You can compare the sandbox technologies: hypervisor vs. Linux kernel containment facilities, but we are doing a lot more than that. There's no doubt that there will be many that want to run Subgraph or parts of Subgraph inside of Qubes for this reason, though we believe Qubes needs strong exploit mitigation throughout, in every VM, and I think wouldn't recommend it until that is the default. 1. Screenshots of Oz' coming TLS Guard, which proxies the TLS handshake to ensure correct TLS session & enforce other policy req's: https://twitter.com/attractr/status/783013051335319553 https://twitter.com/attractr/status/783013051335319553 https://twitter.com/attractr/status/783521883715203073 https://twitter.com/attractr/status/783521883715203073 https://twitter.com/attractr/status/786235879111090176 https://twitter.com/attractr/status/786235879111090176 etc (edited, formatting)

nickpsecurity 10y ago
" Qubes is not going to build this, yet I am running a prototype of it on my SGOS dev laptop." You can do that in Qubes or the architecturally-superior GenodeOS. Genode is FOSS so nothing stops you. Any programs computing with secrets can run in an isolated partition to prevent leaks. Similar with protecting integrity of backups like in some partitioned filesystems. And you get the benefits of subgraph on the inside.
- xdma 10y ago
  No, Qubes hasn't written the TLS client handshake proxy to enforce the policy. Out of scope. That's what I meant, and it's just one example of the things above the level of "Qubes" or "Oz" plumbing that makes Subgraph OS what it is.
- saganus 10y ago
  Sorry for being OT but do you mind explaining a bit what exactly does Genode do/is? I read about it in their web page but I'm not sure I understand the difference between "an OS" and "an OS framework". It seems that they are trying to create an architecture with all components compartmentalized, but it says it can run Linux and Windows so I'm guessing it's virtualizing something at some point. Also, they say they have a reference implementation of the architecture, so I guess the real work is defining that architecture and making an API compatible with what modern OS's do so later on they can jump on board and make it Genode compatible? It sounds very interesting but it feels like I'm misunderstanding a lot and thus hitting a wall here due to lack of knowledge so any pointers are appreciated :)