Re: Comparison to Qubes OS

["infokiller ​" <joweill@icloud.com>]

Michael Raskin wrote:
> >     resources than Qubes'. I mean, if the Qubes folks
> > could fix these issues without a
> >  huge effort, even if it
> >  meant rewriting all the inter-VM communication tools, they probably would. If they
> >  didn't, I assume this is because this is just a huge undertaking (as is the whole
> >  project), and they're busy with other work which has higher priority. I would assume
> >  that you will end up in exactly the same situation.   Note that SpectrumOS is going
> > to make tradeoffs that are complete non-starters for Qubes. 
> > True, but I'm not sure this applies to making GUI tools less buggy, or having better
> > documentation for CLI tools.  
> Yes, it does apply. SpectrumOS is willing to accept quite a bit more of external code with
> good in-the-wild track record inside the trusted code base,
> at least for _most_ tasks. So where Qubes needs to reimplement something with a completely
> different design (allowing minimisation of TCB), Spectrum
> can (at least in the beginning, sometimes grudgingly) take the closest thing in existence
> and add only critically missing parts.
I disagree. Spectrum still needs to write its own GUI tools. Since the Qubes CLI tools are not buggy, presumably the bugs Alyssa ran into are not related to the Qubes design, but rather to GUI programming. As for the CLI tools, I'm really not sure if she can actually reuse any docs, or write less of them. AFAIK, most of the tools in question are related to inter-VM comms, which are not just out there in a fully documented form.
And even if it were the case that it would be possible to significantly reuse existing tools, it's still speculative at best to claim that this will overcome the clear disadvantage in development resources.
> 
> >    A wl_roots
> > based tooling is seriously considered for the first full release, after all���������
> > 
> > Is using wl_roots a non-starter for Qubes? 
> Yes, and I hope it is a complete non-starter on the level of not being worth any
> discussion there.
> 
> I can only remind you, that Qubes has doubts about KVM, a widely used part of the Linux
> kernel, being sufficiently secure. Thety have the same stance
> about half of the features of Xen, the hypervisor they do use.  This does make some things
> Spectrum plans to do for usability and performance much
> harder to implement, as the underlying features are undesirable in the TCB.
> 
> Compared to this, wl_roots is _way_ more dangerous. This is a library which has segfaults
> in relatively normal use, and apparently the users do hit
> these relatively frequently. Some of these seem to survive for months. I have not looked
> whether any of these are exploitable, but for the Qubes level
> of requirements one should just assume it is. Notice that for Spectrum one could also
> reuse some kind of VNC code if wl_roots is eventually considered
> too buggy. For Qubes even VNC libraries are far from good enough.
Well, Qubes does intend to experiment with Wayland [1], though possibly they could use smithay [2] or build their own, hopefully in a memory safe language.
And there's also work in Qubes on moving the GUI part from dom0, which will lower the risk related to the GUI.

[1] https://www.qubes-os.org/gsoc/#wayland-support-in-gui-agent-andor-gui-daemon
[2] https://github.com/Smithay/smithay
> 
> >    There is quite
> > a bit of design space in the gap between ������quite a bit more secure than
> >  Firejail, with the ease of use around plain NixOS plus Firejail������ and ������less
> > secure than
> >  Qubes, but easier to manage������. What do you mean by "quite a bit more
> > secure than firejail"? isn't this side of the spectrum actually
> > "firejail-like security"? 
> Firejail depends on namespaces, which still have some weird behaviours in some corner
> cases, there is a hope that VMs will be a simpler foundation.
I understand, but it sounded like this side of the spectrum should be "using NixOs, maybe with Firejail", in which case the security is Firejail-like.
> 
> >  The way I see it, the following are the major points on
> > the usability-security spectrum for running desktop Linux (or another desktop OS for that
> > matter), starting from the best usability and worst
> > security, and ending in the worst usability and best security:
> > 
> > 1. Run a regular Linux distro (some are better than others in providing quick security
> > updates)
> > 2. Harden the system: sandbox processes, harden the kernel and important userspace
> > libraries like libc, enforce MAC, use Wayland instead of X11, firewall, verified/secure
> > boot, etc. 
> If you do not understand what you are doing well enough, Wayland as you use it might end
> up being less secure than X11, by the way.
What do you mean?
> 
> >  Most users, of course, don't bother and just use
> > (1), which is actually fine in most cases.
> > (2) gives pretty good usability, with the main issues related to sandboxing, since most
> > Linux desktop apps were not built with sandboxing in mind, and the overall experience does
> > not
> > support it well (for example, there's no standard permission dialogs like in Android,
> > where sandboxing works much better in practice). 
> Actually, if you write a few relatively reasonable wrappers around some kind of
> namespace-based sandboxing, usability problems kind of become quite
> different from the normal ones (some UI flows are actually better when the choices are
> trimmed in advance��� and also suddenly a lot of things do not
> need to be chosen uniformly at the entire-system level anymore). 
I'm curious about these wrappers, could you elaborate?
> No idea how much effort
> is to make meaningful GUI permission dialogs. Android ones
> are clearly not meaningful enough, of course.
Android's permission system is far from perfect, but it also targets a very large userbase that doesn't care much about security (as is Windows). And it's still **much** better than desktop Linux.