From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=ALL_TRUSTED,BODY_8BITS, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.3 Received: by atuin.qyliss.net (Postfix, from userid 496) id DBECE90E3; Mon, 15 Jun 2020 13:44:31 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 88FDF90D1; Mon, 15 Jun 2020 13:44:19 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 450D790B8; Mon, 15 Jun 2020 13:44:17 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 7FBDA9107 for ; Mon, 15 Jun 2020 13:44:14 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Subject: Re: Comparison to Qubes OS From: =?utf-8?q?infokiller_=E2=80=8B?= To: discuss@spectrum-os.org Date: Mon, 15 Jun 2020 13:44:14 -0000 Message-ID: <159222865448.15924.2059679729330578851@localhost> In-Reply-To: References: User-Agent: HyperKitty on https://spectrum-os.org/ Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 3UGM7WGMGBXG5ZUMTZJ7SAGUCUYT4E6J X-Message-ID-Hash: 3UGM7WGMGBXG5ZUMTZJ7SAGUCUYT4E6J X-MailFrom: joweill@icloud.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.3.1 Precedence: list List-Id: General high-level discussion about Spectrum Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: 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 Spec= trumOS is going > > to make tradeoffs that are complete non-starters for Qubes.=20 > > True, but I'm not sure this applies to making GUI tools less buggy, o= r having better > > documentation for CLI tools. =20 > 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 somethin= g 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 Qu= bes 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 CL= I 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 r= euse existing tools, it's still speculative at best to claim that this wi= ll overcome the clear disadvantage in development resources. >=20 > > A wl_roots > > based tooling is seriously considered for the first full release, aft= er all=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD > >=20 > > Is using wl_roots a non-starter for Qubes?=20 > Yes, and I hope it is a complete non-starter on the level of not being = worth any > discussion there. >=20 > I can only remind you, that Qubes has doubts about KVM, a widely used p= art 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 do= es make some things > Spectrum plans to do for usability and performance much > harder to implement, as the underlying features are undesirable in the = TCB. >=20 > Compared to this, wl_roots is _way_ more dangerous. This is a library w= hich 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 t= hey 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 wi= ll 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 >=20 > > There is quite > > a bit of design space in the gap between =EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BDquite a bit more secure than > > Firejail, with the ease of use around plain NixOS plus Firejail=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD and =EF=BF=BD=EF=BF=BD=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDless > > secure than > > Qubes, but easier to manage=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD. What do you mean by "quite a bit more > > secure than firejail"? isn't this side of the spectrum actually > > "firejail-like security"?=20 > 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 "us= ing NixOs, maybe with Firejail", in which case the security is Firejail-l= ike. >=20 > > 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: > >=20 > > 1. Run a regular Linux distro (some are better than others in providi= ng quick security > > updates) > > 2. Harden the system: sandbox processes, harden the kernel and import= ant userspace > > libraries like libc, enforce MAC, use Wayland instead of X11, firewal= l, verified/secure > > boot, etc.=20 > 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? >=20 > > 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 sand= boxing, since most > > Linux desktop apps were not built with sandboxing in mind, and the ov= erall experience does > > not > > support it well (for example, there's no standard permission dialogs = like in Android, > > where sandboxing works much better in practice).=20 > 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=EF=BF=BD=EF=BF=BD=EF=BF=BD and also suddenly a lot o= f things do not > need to be chosen uniformly at the entire-system level anymore).=20 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 ve= ry large userbase that doesn't care much about security (as is Windows). = And it's still **much** better than desktop Linux.