Wow, #QubesOS 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,

*OR*

- 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.

Follow

@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 muen.sk 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
1938

youtu.be/HI0x0KYChq4

#fediplay

@rysiek @th

From the bottom of your second link there:

"Update

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).

Sign in to participate in the conversation
(void *) social site

(void*)