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 AE4E38931; Mon, 15 Jun 2020 01:34:12 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 8404E88FC; Mon, 15 Jun 2020 01:34:01 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id E5B0B88E1; Mon, 15 Jun 2020 01:33:58 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id E992A88E0 for ; Mon, 15 Jun 2020 01:33:56 +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 01:33:56 -0000 Message-ID: <159218483690.15924.16175017917976390500@localhost> In-Reply-To: References: User-Agent: HyperKitty on https://spectrum-os.org/ Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 2R4LHGSFS62L5WTOSSVFF736B47LSJUI X-Message-ID-Hash: 2R4LHGSFS62L5WTOSSVFF736B47LSJUI 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: > > - "GUI applications are buggy, command line > > tools > > are mostly > > undocumented": I assume that the reason for this is the lack of > > resources the Qubes project has. However, I don't see how this wi= ll be > > be better in the case of Spectrum which is a new project with one > > developer. My understanding is that a lot of the instability I'= ve > > encountered with > > Qubes's tools comes down to some severe technical debt with their > > inter-VM communication system. This is likely something that is ver= y > > difficult to fix, but easy to learn from. Being a new project allow= s > > Spectrum to learn from Qubes' mistakes. I agree, but I'm still not > > convinced this will be different in the case of Spectrum, having even= more limited dev > > resources than Qubes'. I mean, if the Qubes folks could fix these iss= ues without a > > huge effort, even if it > > meant rewriting all the inter-VM communication tools, they probably w= ould. 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.=20 > Note that SpectrumOS is going to make tradeoffs that are complete non-s= tarters for Qubes. True, but I'm not sure this applies to making GUI tools less buggy, or ha= ving better documentation for CLI tools. Even if Spectrum development wil= l make big compromises, I find it unlikely that these aspects will be improved over Qubes. Now, I'm not saying this is not possible at all. Maybe a 100 new contribu= tors will join the project soon and will make this viable. I just think t= hat this is not a strong selling point of Spectrum, which is somewhat implied in the motivation page. > A wl_roots based tooling is seriously considered for the first full rel= ease, after all=EF=BF=BD=EF=BF=BD=EF=BF=BD Is using wl_roots a non-starter for Qubes? > A lot of problems for Qubes is that things are hard to do without makin= g security slightly > worse than what Qubes has now. Spectrum is definitely not going to achi= eve this level of > security anytime soon for various reasons, and the goal is more to find= the best trade-off > between security and usability.=20 >=20 > There is quite a bit of design space in the gap between =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 and =EF=BF=BD=EF=BF=BDless secure than > Qubes, but easier to manage=EF=BF=BD=EF=BF=BD. What do you mean by "quite a bit more secure than firejail"? isn't this s= ide of the spectrum actually "firejail-like security"? The way I see it, the following are the major points on the usability-sec= urity 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 q= uick security updates) 2. Harden the system: sandbox processes, harden the kernel and important = userspace libraries like libc, enforce MAC, use Wayland instead of X11, f= irewall, verified/secure boot, etc. 3. Use Qubes Most users, of course, don't bother and just use (1), which is actually f= ine in most cases. (2) gives pretty good usability, with the main issues related to sandboxi= ng, 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). Theoretically, people could use (2), run untrusted software in VMs to get= strong sandboxing but still be able to use most software, and get pretty= good security. In practice this doesn't quite work because running stuff in dedicated VMs is not streamlined enough, so peop= le just don't do it. Then there's (3), which is the most secure, but has some usability issues= that were already mentioned. So Spectrum can fill the gap between (2) an= d (3).