Wow, is way more usable once I upgraded my laptop to 40GiB of RAM.


This is not okay. None of this is okay.

Only having a choice between:

- running an OS that runs fast, has GPU acceleration available for applications, does not drain my battery like there's no tomorrow, and does not require stupid amounts of RAM,


- running an OS that is perhaps reasonably secure…

…is simply not acceptable.

Not the least because that choice is only even available to people who can afford 40GiB of RAM.

· · Web · 6 · 9 · 21

@rysiek Doubly so as Qubes used to run on 4Gb reasonably. Literally 1/10th the resources.

@feonixrift I'm sure it can run reasonably in 8GiB. I've been running it in 12GiB and then 16GiB and it was ~fine-ish, but I had to be careful which cubes I run simultaneously.

What really kills it is the browsers. And I include any Electron app in that group. Stop writing Electron apps people, for the love of everything that is holy! Just damn stop!

The fact that as a developer someone has 32GiB of RAM to play with doesn't mean it's okay to demand that kind of resources on a user machine.

@rysiek Even when I used it browsers were the unholy ram-breaker. I could at the time run up to about 5 vm with up to 3 of them using firefox, but this was before electron.

@rysiek is there an option of somewhat relaxing your definition of "reasonably secure"?

@isagalaev yes.

What I want is good compartmentalization on the desktop. I am hoping can provide that:

SpectrumOS will be somewhat less secure than QubesOS, from what I gather, but still way more secure than any "monokernel" system, so to speak.

We (as in: the tech industry) are still figuring shit out, obviously. But compartmentalization needs to be front-and-center for any reasonably secure system.

@rysiek could you explain why monokernel makes system less secure? Especially for a desktop system that doesn't run publicly accessible services, presumably.

@isagalaev compromise of a kernel — that can come from a driver that runs in ring0, etc — compromises the whole system.

On Qubes, a full compromise would require several different layers to be compromised, meaning several 0days for completely different pieces of software dropped on a single attack. That rises the bar considerably.

@isagalaev also, as mentioned in a separate part of this thread, compromise of one desktop application means compromise of all user data.

And that's a way way waaaay lower bar than kernel compromise.

@rysiek I'm a big fan of the Qubes separation model, less of a fan of the "run heavy weight Linux installations in each VM" model. It seems like there should be a modern design using KVM and a lightweight immutable control domain, a video domain with GPU pass through, and firecracker/unikernels for the various helper VMs.

@rysiek SpectrumOS does have many of the features that I'd like to see, although my dream "dom0 replacement" would have no POSIX runtime, no device drives, no filesystem, and look more like the AWS Lambda/Firecracker runtime than even a Nix-based OS.

@th @rysiek works with small "subjects" within VMs, but I'm not sure if that's really closer to what you're looking for.

@th @rysiek

chroot, chroot
it's after boot we go
a chroot jail
will rarely fail
chroot, chroot

Heigh Ho - Snow White and the Seven Dwarfs


@rysiek @th

From the bottom of your second link there:


If applications support chroot, it might still be wise to enable it. It's often very easy to configure and it will probably delay an attacker."

@hhardy01 @th "delay" being the operative word here.

Plus, configuring chroots in a secure way is *difficult*. Same goes for AppArmor, SElinux, and similar tools. The problem with them is that they are default-open, so to speak (chroots a bit less, to be fair).

I much prefer the model of "default-closed" because this means you'll debug locked-out stuff until you get it working, at which point it's only open as much as it needs to be, and no more.

@hhardy01 @th don't get me wrong, any step that delays the attacker is worth considering. I'm running docker on my personal infra, and was doing that at $OLDJOB, and even though it is not, strictly speaking, a security tool, it did improve the security of that infra quite a bit.

In no small part thanks to the "default-closed" nature of Docker (as in, you need to explicitly give access to host directories, networking, open ports, etc).

@rysiek Why do you consider other distros not reasonably secure?

@mimi89999 because a compromise of the kernel is a compromise of the whole system.

And also, because compromise of one application run as a user means a complete compromise of all user data.

On QubesOS, my personal stuff runs in one VM, my "for shits and giggles" browser runs in a different VM, my work stuff in yet another one, my network stack is separated from it all, and I open PDFs in disposable VMs that have no access to anything.

Impossible to achieve that level of separation on a regular distro.

@mimi89999 so, a random link clicked in my untrusted browser, even if it does compromise my untrusted browser, does not affect, at all, any other thing I am running. And once I kill the disposable VM, it's... gone.

Unless it's an exploit that breaks out of:
1. tab separation
2. browser sandbox
3. kernel security measures in the VM
4. XEN-enforced compartmentalization.

In which case, chapeau-bas, you deserve to pwn me.

@mimi89999 just to be clear, for most people most of the time, an up-to-date GNU/Linux system is good enough.

But if you're an activist, a journalist, an opposition politician in places like Myanmar, China, Poland or the USA, you need something better. And the only thing there is, QubesOS, comes with friction and cost that is hard to bear.

@rysiek the problem is that many VIPs are vulnerable to simple attacks like phishing and getting them protected against it will already be a great success!

Teaching them how to use QubesOS will be extremely difficult.

@mimi89999 that is another important point, which I believe I've made in this thread somewhere.

@rysiek If you were to advise an activist, what system and device would you give them?

@mimi89999 I would sit down with them and spend considerable time to understand their needs, the threats their facing, the resources they have available, and time and effort they are willing spend on learning new tools well, before I would even start thinking about considering getting to a point of pondering to answer such a question.

Threat modelling is a thing.

@rysiek What would prevent a very powerful actor from getting 2 more 0-days?

@mimi89999 probably nothing. But it raises the bar (difficulty, financial, etc) dramatically.

@mimi89999 yeah, sure. But, see, I don't find debating with people taking nihilistic positions like this intellectually interesting. If nothing matters, why even debate?

So thanks for the fish, I'll go something else now. 👍

@rysiek The problem is that they could use other strategies like social engineering and they will get the user lost and trick them into doing something stupid. That will be much, much cheaper than a chain of 0-days.

@mimi89999 "why even bother locking the door, the baddies can get lockpicks!"

@rysiek @mimi89999 yes. And for such architecture (good in term of security) you still have pay a lot in meaning of computer resources. Also, you still have "single point of failure" - as devices and it's driveres. Hardware is unsafe too and even 1000 VMs don't help you if there is 0day in for example graphics card (driver or... hardware :D) or network, or sound or processor (oh yes, we have it while ago).Secure OS on insecure hadware is for me sort of contradiction.

@seachdamh @mimi89999 QubesOS deals with this pretty well, by not having any networking in dom0, assigning all devices to special sys-usb VM, and assigning the necessary networking devices to sys-net VM.

So a compromised device either:
- has no network access (if in dom0, like GPU),
- has network access but no data access (if in sys-net; you can use a separate VPN/Tor VM to provide network access to AppVMs thus denying sys-net access to data in flight)
- or has no access to network nor data (if in sys-usb)

@seachdamh @mimi89999 and then it's up to the user to decide if that USB stick really needs to be made available to that AppVM that has all the important data, and maybe network access too, or if it's better to start a network-less DispVM, assign the USB thumbdrive to it, and copy the data from the important data VM there to then copy it to the USB drive from there.

It's a hassle. But it's way more secure than anything else generally available.

@rysiek One option that might fit your bill is Android os, i.e. Android-x86. The goal of most derivative projects is so you can play Android games on a laptop. At the same time with the right mix of software you can get a reasonable "daily driver".

From a personal device perspective, I think the Android security model provides a good blue print for creating secure, consumer friendly, usable devices. We just need some work to port it to the desktop world.

@rysiek + A Laptop that can take 40GiB of Ram, which is probably even more expensive

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!