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 16:42:02 +0200 [thread overview]
Message-ID: <E1jkqCG-0001yN-8t.7c6f434c-mail-ru@smtp34.i.mail.ru> (raw)
In-Reply-To: <159222865448.15924.2059679729330578851@localhost>
>I disagree. Spectrum still needs to write its own GUI tools.
There are some XDG tools that can be reused wholesale.
>> > 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.
SpectrumOS will use small VMs, not containers.
>> > 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?
Well, most compositors allow clients quite a lot of things that theoretically should be
permission-checked, so there is not as much good to overcome the drawbacks of a lot of code
being still a bit raw.
>> > 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?
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 program running inside
nsjail. Of course if I bother to do all that, there is also use of single-use UIDs on top
of restrictions by mount namespaces.
It's not that much code, and in my case it is in Common Lisp.
And then it is just all the boring stuff that is annoying elsewhere like using different
resolv.conf for different applications and giving applications access only through proxy
and only picking from the files that the application should use and not navigating the
entire storage.
So I watch SpectrumOS mostly looking at the CrosVM work and when it will be sufficient
for replacing containers and socket proxying with VMs and virtio-based socket proxying.
>> 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.
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 rare case of desktop Linux
where people _also_ use UID segregation. There is a chance that XDG-portal 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 usable as a general-purpose
computing platform, but this seems not to be forced by the permission system design in any way.
next prev parent reply other threads:[~2020-06-15 14:35 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
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 [this message]
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=E1jkqCG-0001yN-8t.7c6f434c-mail-ru@smtp34.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).