From: "infokiller " <joweill@icloud.com>
To: discuss@spectrum-os.org
Subject: Re: Comparison to Qubes OS
Date: Mon, 15 Jun 2020 15:29:20 -0000 [thread overview]
Message-ID: <159223496042.15924.6966658213223423654@localhost> (raw)
In-Reply-To: <E1jkqCG-0001yN-8t.7c6f434c-mail-ru@smtp34.i.mail.ru>
Michael Raskin wrote:
> > 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.
I understand that: I was referring to a hypothetical system running NixOS with Firejail, which is lower security and higher usability than Spectrum/Qubes.
>
> > 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.
Yeah, I find this is indeed the most annoying stuff when I'm using Firejail. It's especially annoying if I realize I want to open a file in the sandboxed 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 bothered to check).
>
> 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.
I think Flatpak is a step in the right direction, but is still far from being everywhere, and has its own share of issues. It also doesn't solve the 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.
prev parent reply other threads:[~2020-06-15 15:29 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
2020-06-15 15:29 ` infokiller [this message]
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=159223496042.15924.6966658213223423654@localhost \
--to=joweill@icloud.com \
--cc=discuss@spectrum-os.org \
/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).