From: Michael Raskin <7c6f434c@mail.ru>
To: joweill@icloud.com, discuss@spectrum-os.org
Subject: Re: Comparison to Qubes OS
Date: Mon, 15 Jun 2020 13:38:22 +0200 [thread overview]
Message-ID: <E1jknKV-0007sZ-Vn.7c6f434c-mail-ru@smtp40.i.mail.ru> (raw)
In-Reply-To: <159218483690.15924.16175017917976390500@localhost>
>> > 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.
>> 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.
>> 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.
>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.
>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). No idea how much effort is to make meaningful GUI permission dialogs. Android ones
are clearly not meaningful enough, of course.
next prev parent reply other threads:[~2020-06-15 11:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-12 11:06 joweill
2020-06-12 11:28 ` Michał "rysiek" Woźniak
2020-06-12 11:54 ` infokiller
2020-06-12 12:02 ` Michał "rysiek" Woźniak
2020-06-13 11:19 ` Alyssa Ross
2020-06-13 11:38 ` Alyssa Ross
2020-06-14 20:19 ` infokiller
2020-06-14 21:27 ` Alyssa Ross
2020-06-14 22:19 ` Michał "rysiek" Woźniak
2020-06-15 1:59 ` infokiller
2020-06-15 1:54 ` infokiller
2020-06-14 21:13 ` Michael Raskin
2020-06-15 1:33 ` infokiller
2020-06-15 11:38 ` Michael Raskin [this message]
2020-06-15 13:44 ` infokiller
2020-06-15 14:06 ` Michał "rysiek" Woźniak
2020-06-15 15:07 ` infokiller
2020-06-15 14:42 ` Michael Raskin
2020-06-15 15:29 ` infokiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E1jknKV-0007sZ-Vn.7c6f434c-mail-ru@smtp40.i.mail.ru \
--to=7c6f434c@mail.ru \
--cc=discuss@spectrum-os.org \
--cc=joweill@icloud.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).