Don’t forget that, the VMs in Qubes should still be secure.
Running ChromeOS Flex (or Android?) or kicksecure is good. Whonix is good too, but it seems it’s for privacy.
QubesOS – A reasonably secure operating system
101–110 of 141 posts
Re: QubesOS – A reasonably secure operating system
#102Daily drove qubes for 5.5 years. I liked it a lot.
Re: QubesOS – A reasonably secure operating system
#103I used it when I worked as a hiring manager. For this task it is ideal. All the behavioral security measures, like only to open attachments from people you trust, break down when your job description is basically to figure out who you can trust. Qubes comes with a "Convert to trusted PDF" out of the box. Joanna Rutkowska explained how it works under the hood pretty nicely[1]. The tldr is that it is very thorough. Wit…
You can use something similar on macOS, Windows or Linux, based on Docker containers, see Dangerzone: https://github.com/freedomofpress/dangerzone
Dangerzone is an implementation of a concept known as CDR (Content Disarm & Reconstruction), where you convert anything to an image inside a sandbox, and then convert the raw pixel data back into an image inside a different sandbox.
It is a common workflow inside the government or other places where you need to move data across airgaps, or view content that is highly untrusted.
Shameless plug, I wrote my own that supports over 200 file formats: https://preview.ninja/
Re: QubesOS – A reasonably secure operating system
#104I really like QubesOS, but you cannot run VMs inside a qube, or other things that require VMs like Docker Desktop for Linux, because the xen hypervisor does not support nested virtualization.
Huh… why does Docker require VMs on Linux? Isn’t the selling point of Docker that it uses the same kernel on Linux? And it should be quite lightweight as it’s just a container… It’s not that I don’t believe you but I don’t understand it… why would you need VM on Linux for Docker? edit: huh https://docs.docker.com/desktop/faqs/linuxfaqs/#:~:text=Dock... . that’s… a bit stupid in my opinion. But you can always just use…
> Huh… why does Docker require VMs on Linux? Isn’t the selling point of Docker that it uses the same kernel on Linux?
docker has been playing rather loose with security for quite a long time in the past, so I per-se wouldn't trust it to be secure
additionally there are (oversimplified) 3 ways to run it:
1. a "root" deamon, the default docker daemon setup in most distros and the way docker originally was designed to be used. This is needed for some advanced (non secure) features (which IMHO should not exist) but has pretty serve security issues IMHO, like either being in the docker group being a de-facto root/sudo or it forcing you to use sudo all the time and bugs in the docker deamon potentially leading to catastrophic exploits.
2. as a unprivileged user using cgroupsv2 like podman does by default, this has some limitations but works really well and as long as "linux containers" are secure it should be secure (oversimplified). Still the security of containers isn't perfect as they share the kernel. As a rule of thump only use if you get reliable kernel security updates.
3. starting VMs, much more overhead in many ways and needing virtualization, but works with old "outdated" kernels or hardened kernels(1) not allowing unprivileged cgroups
The 3rd method is the most secure and works across most dirstros/linux setups even if unusual setup and is the same kind of path docker takes on windows/mac. So no wonder a product like Docker Desktop uses it. Also the overhead of virtualization is today not "that" bad.
The the first method is still the default method for docker CLI on most linux distros is honestly far beyond my understanding. In the past pre reliable cgroups v2, maybe, but today omg no. It has some valid use cases, but the default should be VMs or unprivileged containers especially on desktop systems (whatever distro maintainers prefer).
----
(1): On instresting conflict is security hardening vs. unprivileged cgroups/containers. On one side unprivileged cgroups allow a lot of additional security. For example they allow running various sandboxes without needing a suid binary or using sudo for setting up the sandbox. Which is really grate. At the same time (oversimplified) it increases the security sensitive kernel interface by a non negligible margin, which isn't grate and hence why hardened linux often disables it by default.
EDIT: Sorry for the bad spelling, I need to go to bed.
Re: QubesOS – A reasonably secure operating system
#105The people who work on QubesOS are phenomenal at what they've accomplished. It's not everyone's cup of tea, not least of all because of the hardware requirements and battery drain. All the same, their commitment to developing a reasonably usable, but above all a highly secure OS clearly shows.
Re: QubesOS – A reasonably secure operating system
#106QubesOS is very cool but I've always thought it'd cool/better if it was a patchset or repo on top of an existing distro like Archlinux or NixOS. I think that would be useful so you could adopt features from QubesOS individually and swap out different components. For example, it'd be nice to use KVM (QEMU or even crosvm) instead of Xen or build a Wayland based system instead of X11.
They did consider KVM initially; I don't know how much things have changed and if they've reconsidered. The reasoning was that KVM's means of virtualization is too closely coupled with the Linux kernel, whereas Xen's hypervisor and dom0 are more separable.
> In Xen, at no point does the execution path jump out of the hypervisor to e.g. Dom0. Everything is contained within the hypervisor. Consequently itʼs easier to perform the careful security code audit of the Xen hypervisor, as itʼs clear which code really belongs to the hypervisor.
From the original 0.3 spec
Re: QubesOS – A reasonably secure operating system
#107I've been using Qubes for the past 2 years while going to school, and I found it really fun and helpful. A lot of professors had me download random closed source software from random websites during the pandemic, and it was easier to download it to a VM than to convince them about Free Software. More than that though it's been really helpful just for my own workflow. I can hit a keybind and start working from essenti…
> I accidentally added in a space when typing `rm -rf ~/Arduino` which made it `rm -rf ~ /Arduino`
NGL I laughed out loud reading this.
I do feel sorry I laughed though.
Re: QubesOS – A reasonably secure operating system
#108Related. Others? Qubes OS 4.2-rc1 is available for testing - https://news.ycombinator.com/item?id=36178205 - June 2023 (3 comments) New user guide: How to organize your qubes - https://news.ycombinator.com/item?id=33396604 - Oct 2022 (15 comments) What Is Qubes OS? - https://news.ycombinator.com/item?id=32036899 - July 2022 (82 comments) Qubes OS: A reasonably secure operating system - https://news.ycombinator.com/it…
Possibly to some extent
Intel x86 considered harmful – survey of attacks against x86 over last 10 years - https://news.ycombinator.com/item?id=10458318
Re: QubesOS – A reasonably secure operating system
#109I bought a Librem laptop for Qubes support.
Feels like home.
Re: QubesOS – A reasonably secure operating system
#110How is this different than an immutable distro like Fedora Silverblue?