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 D3731958B; Mon, 15 Jun 2020 15:29:34 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id EB92894F2; Mon, 15 Jun 2020 15:29:24 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 496) id 6894094D6; Mon, 15 Jun 2020 15:29:22 +0000 (UTC) Received: from localhost (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 7038194D4 for ; Mon, 15 Jun 2020 15:29:20 +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 15:29:20 -0000 Message-ID: <159223496042.15924.6966658213223423654@localhost> In-Reply-To: References: User-Agent: HyperKitty on https://spectrum-os.org/ Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 7M7WUBKXXQTG4T2LFBSIPTRYW3TXR64E X-Message-ID-Hash: 7M7WUBKXXQTG4T2LFBSIPTRYW3TXR64E 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: > > I disagree. Spectrum still needs to write its own GUI > > tools. =20 > There are some XDG tools that can be reused wholesale. >=20 > > Qubes, but easier to manage=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=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. 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 st= ill > > have some weird behaviours in some corner > > cases, there is a hope that VMs will be a simpler foundation. I unde= rstand, but it > > sounded like this side of the spectrum should be "using NixOs, maybe = with > > Firejail", in which case the security is Firejail-like.=20 > SpectrumOS will use small VMs, not containers. I understand that: I was referring to a hypothetical system running NixOS= with Firejail, which is lower security and higher usability than Spectru= m/Qubes. >=20 > > 2. Harden the system: sandbox processes, harden the > > kernel and important userspace > > libraries like libc, enforce MAC, use Wayland instead of X11, firewa= ll, 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?=20 > Well, most compositors allow clients quite a lot of things that theoret= ically should be=20 > permission-checked, so there is not as much good to overcome the drawba= cks of a lot of > code > being still a bit raw. >=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 san= dboxing, since most > > Linux desktop apps were not built with sandboxing in mind, and the o= verall 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 wh= en the choices are > > trimmed in advance=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 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?=20 > Well, I run browser instances and PDF/image/video viewers inside nsjail= , and the wrappers > _mainly_ just prepare a reasonably restricted access to give the progra= m running inside=20 > nsjail. Of course if I bother to do all that, there is also use of sing= le-use UIDs on top > of restrictions by mount namespaces. >=20 > It's not that much code, and in my case it is in Common Lisp. >=20 > And then it is just all the boring stuff that is annoying elsewhere lik= e using different > resolv.conf for different applications and giving applications access o= nly through proxy > and only picking from the files that the application should use and not= navigating the > entire storage. Yeah, I find this is indeed the most annoying stuff when I'm using Fireja= il. It's especially annoying if I realize I want to open a file in the sa= ndboxed app that I didn't whitelist, which means I rerun it (there may be= a way to whitelist files after the app is already running, but I never b= othered to check). >=20 > So I watch SpectrumOS mostly looking at the CrosVM work and when it wil= l be sufficient=20 > for replacing containers and socket proxying with VMs and virtio-based = socket proxying. >=20 > > No idea how > > much effort > > is to make meaningful GUI permission dialogs. Android ones > > are clearly not meaningful enough, of course. Android's permission s= ystem is > > far from perfect, but it also targets a very large userbase that does= n't care much > > about security (as is Windows). And it's still **much** better than d= esktop Linux. > >=20 > It is unclear that Android in practice (not how the intents should have= been used) is > better than > desktop Linux with Flatpack everywhere, let alone the unfortunately rar= e case of desktop > Linux > where people _also_ use UID segregation. There is a chance that XDG-por= tal stuff ends up > closer to > how intents should have been used than what we currently see on Android= . And recently it > looks like > Android is now going to give up the remaining appearances of being usab= le as a > general-purpose > computing platform, but this seems not to be forced by the permission s= ystem design in any > way. I think Flatpak is a step in the right direction, but is still far from b= eing everywhere, and has its own share of issues. It also doesn't solve t= he issue of apps that were not built with a permission system. Android has other issues, of course, like very slow (it at all) security = updates, but if you're using a recent Pixel you are probably much better = off than using desktop Linux.