23 ms·

QubesOS – A reasonably secure operating system

176 points by TheFreim 3y ago

sigmonsays 3y ago
this is my next OS to experiment with. However i'm worried my toy laptop with 16gb of ram (thinkpad t480) wont cut it. Anyone want to chime in here?
- polotics 3y ago
  16GB of RAM is adequate for Qubes, in practice you end up running a handful of Xen VMs, with most of the VMs (vault, disposable,...) using little RAM.
  - mdp2021 3y ago
    The system requirements are specified as: minimum 6GB RAM; 16GB recommended https://www.qubes-os.org/doc/system-requirements/ https://www.qubes-os.org/doc/system-requirements/
- Forbo 3y ago
  Last time I tried to throw it on an old box it couldn't handle it due to the lack of IOMMU. Granted this was like... 5 or so years ago? I think my newer laptop could probably handle it, so maybe it would be worth giving another shot.
  - Syonyk 3y ago
    There are ways to get it running without an IOMMU, mostly involving making your NetVM and such paravirtualized. You just lose basically all of the hardware isolation benefits there. But for playing around, especially on a trusted LAN, you should be able to get it working. If you can't figure it out, jump on the IRC channel - there are a few people in there pretty good at weird hardware hacking for Qubes.
- weinzierl 3y ago
  I used it productively (see my other comment) a couple of years a ago on an average Dell Inspiron. It worked pretty well, no complaints.
- jamal-kumar 3y ago
  I've used this as my daily driver before when my workflow needed more crossplatform operability between windows and different varieties of linux. This was a long while ago on some old 2013 laptop with 16 gigs of ram and it worked fine. The real thing you gotta watch out for is full compatibility with all the virtualization extensions it needs in the processor. Key in that old laptop working was that it was an i7.
- Syonyk 3y ago
  It's fine for light to moderate use, just don't expect to run a ton of AppVMs at once. I've got an X250 (2C/4T) 16GB gutless wonder as my Qubes laptop, and it's fine. Qubes has memory balancing/clawback from VMs, so you can in practice have more AppVMs open than you'd expect - they'll be using less RAM, but it works. If you're on a short-RAM laptop, though, definitely reduce Dom0's memory allocation. It defaults to 4GB, and you're perfectly fine with 2GB or perhaps even 1GB - there's not much going on in it, and that RAM is better used for AppVMs. If you're short on cores, you might also look at the "sched-gran=core" flag to Xen. This allows hyperthreading, but ensures that hyperthreads are only ever scheduled in the same VM (and as the threat model assumes "anything in a VM can read anything else in a VM," a hyperthread-based leak doesn't gain an attacker any access you wouldn't otherwise have). The performance gains on a laptop can be noticeable. Don't expect great battery life, though. Xen's power management is "present and accounted for," at best. There's also an incantation to disable turbo that helps a lot when mobile.
- hiatus 3y ago
  Runs fine on my framework laptop with 16gb of ram.
- nasc_ 3y ago
  I've been daily driving it on my Thinkpad T580 with 16gb of ram for the past two years. I really enjoy it. Very occasionally it tells me that it's running out of RAM, but when that happens it's usually because I forgot to shutdown some VMs. Besides for that everything works great. I'd recommend using an SSD though with at least 512GB of storage, but better with 1TB.
weinzierl 3y ago
I 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. With Qubes it is convenient too. I used Qubes to open the application mails and their attachments and converted the interesting ones to trusted PDFs which I then forwarded to the relevant people. All further communication was only with the trusted versions. [1] https://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html https://blog.invisiblethings.org/2013/02/21/converting-untru...
- neodypsis 3y ago
  You can use something similar on macOS, Windows or Linux, based on Docker containers, see Dangerzone: https://github.com/freedomofpress/dangerzone https://github.com/freedomofpress/dangerzone
  - weinzierl 3y ago
    I didn't know about that but that looks really nice. From a quick glance I understand that they can even utilize OCR to make the trusted PDF into more than an image container. Back in the day when I used Qubes it could not do that. (I haven't used it for a while so I don't know if it can now) I still think security-wise Qubes is a bit better because it relies on VMs instead of containers.
  - Syonyk 3y ago
    The problem is that containers rely on the OS kernel to enforce separation, and kernel exploits are an awful lot less rare than anyone would prefer. If someone is delivering targeted malware to a company through HR channels, it's safe to assume that if they can escape the document viewer, they can probably also try for a local root/kernel exploit and escape the container. Containers are separation of convenience - not a hard security boundary.
flashback2199 3y ago
I 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.
- frugalmail 3y ago
  Double whammy, because sadly you can't run it in a VM either. At least that's my experience.
  - Syonyk 3y ago
    If your hypervisor supports nested virtualization, it should work. It'll probably grumble about the lack of IOMMU and various other things, but you should be able to run it in VMWare or KVM, if you're willing to jump through some hoops. Not sure why you'd bother, though. If you're already spinning up VMs, just use that capability. Qubes makes "spinning up a ton of VMs on the iron" a lot easier and more usable.
    - flashback2199 3y ago
      > Not sure why you'd bother Because some software expects to run a VM itself such as Docker Desktop which I said in my original comment.
      - Syonyk 3y ago
        And if you'll note, under your original comment I added some detail on how to enable nested virtualization in Qubes.
        flashback2199 3y ago
        Replied
    - kj4ips 3y ago
      My understanding is that this is how Qubes itself is tested.
aborsy 3y ago
Is QubesOS used in the security companies or community? I know it’s used in Mullvad, and recommended by Snowden (but he isn’t a security specialist). I have been playing with it, and it might work as a daily driver.
- Izmaki 3y ago
  It's not often that the benefits QubesOS brings are what security companies (or the community) needs. If you do malware analysis, Windows VMs in isolation on a throw-away laptop is better. If you do penetration testing, Windows or regular Linux will be better, too. If you do extremely sensitive communication you're in a very niche group of people and chances are you're using a provided equipment by your superior (e.g., modified laptops).
  - anonym29 3y ago
    >If you do malware analysis, Windows VMs in isolation on a throw-away laptop is better. >If you do penetration testing, Windows or regular Linux will be better, too. I am going to firmly disagree with these two points. I've been a red teamer at one of the three big cloud providers for over a decade, and a passionate hobbyist with both malware RE and offsec (CTFs, bug bounties, etc). I've reversed easily 2000+ different samples of malware, have more CVEs than I can count (several dozen), and can make my way through a corporate network quicker than almost any known APT group. I use Windows qubes, both as sandboxes and for certain utilities that only run on Windows, and I do pentesting from Linux-based qubes. There is precisely one restriction I face with Qubes in my entire line of work: even with two GPU's installed for isolation purposes, Nvidia GPU's (even with FLReset+) do not like being passed through by Xen. Older AMD cards like my RX 580 work fine. That said, there are only two things I'd have any use out of a GPU for - hash cracking (obvious) and LLM workloads (code generation, to speed up PoC prototyping, tool development, etc). Fortunately, I have access to a six figure rig dedicated to hash cracking at work, as well as effectively unlimited usage of a non-local code generation LLM. There is no circumstance in which running Windows on bare metal is ideal or optimal in any way whatsoever for just about any kind of security work. Linux is better in some ways, but even then, segregating workflows in ring3/userland is a must, and Qubes makes this painless, quick, and easy compared to spinning up a bunch of VMs in your distro of choice. The USP of Qubes isn't that it does anything magic to make a level of security possible that isn't on other platforms, it's how it makes attaining and maintaining that level of security so effortless and seamless compared to other solutions. The only alternative I've played with that comes close (imo) is Subgraph OS, but it's really not an exaggeration to say that project is absolutely still in alpha status of development, and I would not yet rely on that for sensitive workloads. One aspect of what you said that I do agree with and wholeheartedly support is hardware isolation. Even with Qubes, hardware isolation is a fine solution to Xen HV exploits, for the tiny handful that have affected Qubes' Xen implementation.
GoofballJones 3y ago
I hadn't checked on this project in some time, and last I looked it seemed to be stagnant. Good to see it going strong again. I just remember that, hardware wise, there wasn't a lot of things that could run all aspects of the OS and be 100% with it. The "certified hardware" on the site also looks like it's out of date.
- fsflover 3y ago
  This project was never stagnant, a lot of things are always happening here: https://github.com/QubesOS/qubes-issues/issues https://github.com/QubesOS/qubes-issues/issues. Concerning the certified hardware, few vendors try to make the certification, and also coreboot is required: https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements https://www.qubes-os.org/doc/certified-hardware/#hardware-ce...
- eduction 3y ago
  It has remained quite active since I started using Qubes in 2016. I think when Joanna left day to day work it's possible things slowed a bit but I didn't have enough context since that wasn't long after I started. Based on hanging out in the support forums it seems like there have been some pretty large groups of new users, honestly I have no idea why many came at once but they did. Of course for a project this small, "large" is relative. The current work includes making dom0 smaller by delegating the gui to a service Qube.
barbariangrunge 3y ago
Anybody here actually use it day to day? Or is this more of a server OS?
- beardog 3y ago
  See my top level comment about daily driving it.
- Zambyte 3y ago
  > Or is this more of a server OS? It's specifically designed for desktop use https://www.qubes-os.org/intro/ https://www.qubes-os.org/intro/
- Infernal 3y ago
  It is explicitly not a server OS, it really only makes sense as a graphical workstation OS.
- aborsy 3y ago
  It’s meant to be used in a single-user laptop or desktop.
- Syonyk 3y ago
  Yeah. I started playing with it about 2 years ago, and I now caution people that "it's really a bit virus-like." It went from being on one "play" computer to being my daily driver OS on 4 machines in that time. It's fine. You just have to be willing to operate on a "If I can't do it, then I must not need to do it" sort of basis with things like media. But that's no real problem for me, I hate video anyway.
beardog 3y ago
I love Qubes a lot, I daily drove it for a few years and still have it on a laptop. but i would not recommend it even to most technical people, mainly because you forfeit the ability to run things on bare metal. "dom0" is the same as on normal xen - it is a VM and has the associated overhead still. On top of that, the official Qubes dom0 runs a very outdated fedora version. I am instead writing my own code to automate libvirt to replicate much of Qubes' functionality (ephemeral roots for vms, disposable vm support, GUI isolation) so i can still have Qubes security for most of my apps but fully exercise my hardware when I want. There are also some minor criticisms i have of Qubes' default, mainly that appvms have passwordless sudo by default and less importantly, no MAC such as apparmor. Passwordless sudo arguably makes it somewhat easier to break out of the VM and no in-vm sandboxing means you have to run every in a separate VM unless you want to set that up yourself. For example i don't really want my work thunderbird to have access to my work browser, so a single "work" domain isn't enough for me.
- beardog 3y ago
  To add, it works quite well if you can accept the caveats of no (easy/default) GPU access (so no gaming). It is not a lot slower if you have enough ram to keep your VMs booted, i mainly noticed a difference in i/o speed but that may have been my particular setup. You aren't meant to mess with dom0 (so also your desktop) much, so ricers won't like it unless they are willing to break the security model somewhat. It is also not meant to be a shared PC. Windows (10) support is pretty mediocre but it does work. I was able to do a WFH job that required windows using it without pain - you don't get seamless windows though.
- Syonyk 3y ago
  The threat model assumes that any code in a VM can, with some application of effort, access anything else in that VM. Given the relatively low cost of local root exploits and kernel exploits, this is reasonable. Passwordless sudo is simply a reminder that you can't rely on intra-vm separation of anything you care about separating. If you wanted to add additional hardening within a VM, it's supported - create your own templateVM for it, and use it. It's just not the default, and I generally agree with it. If you trust the OS kernel and features to keep things separated, there's no reason to run Qubes in the first place.
legrande 3y ago
What kind of threat model requires someone to use Qubes? I know Snowden uses it and there's even a testimonial of him on the Qubes site recommending it. Is this for people on 'lists' or are high value targets because they visited the wrong site or said something the authorities didn't like and their machines are now being targeted?
- beardog 3y ago
  Honestly you don't need to be super paranoid to benefit from Qubes. Windows and Linux default sandboxing is still pretty mediocre at best, people can't be perfect with security all the time and sometimes even legit programs get compromised, so the sandboxing security model helps contain the damage. That said you can still setup sandboxing without Qubes.
- fsflover 3y ago
  I would say, almost anyone running anything untrusted from time to time can benefit from the strong hardware virtualization. Qubes is my daily driver by the way. My attempt of explaining it to a layman: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
  - Syonyk 3y ago
    And "anything untrusted" includes "any use of the internet." Browser escapes are cheap enough and common enough that we've seen malware delivered through advertising networks before.
- thoughtbag 3y ago
  I know what Theo says about (x86) virtualization[1], but I think it's still useful to virtually separate your random browsing the web from things like health and banking, or where you keep your ssh keys (if you don't use a Yubikey or similar to keep it off your laptop) -- or other secrets. You can be a victim of a random drive-by, you don't have to be a person on a "list". [1] https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582
KingMachiavelli 3y ago
QubesOS 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.
- Levitating 3y ago
  I guess adding more variation to QubesOS systems would make it less secure as there is more room for bugs.
- coppsilgold 3y ago
  There is actually a project which aims to do that: <https://spectrum-os.org https://spectrum-os.org> Unrelated to QubesOS.
- Syonyk 3y ago
  If you have the skills to port the tools to KVM, please do so. There's a shortage of sufficiently paranoid low level sorts with the time and interest in the hacking on Qubes. Getting it working on ARM is also of interest.
- snvzz 3y ago
  >For example, it'd be nice to use KVM (QEMU or even crosvm) instead of Xen Or even better, seL4, for which an effort exists[0]. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
- vacuity 3y ago
  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
DeathArrow 3y ago
>Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called qubes. What's wrong with containers? They are supposed to provide better performance than VMs. Are containers less secure?
- vorpalhex 3y ago
  Yes. Containers generally assume a non-hostile workload and don't make assurances about certain kinds of tampering.
- deleted 3y ago
  [deleted]
- hiatus 3y ago
  Containers rely on the security of the operating system. If you can compromise the system you can potentially compromise your neighbors. VMs rely on the security of the hypervisor.
- ahmedalsudani 3y ago
  Yes, they are less secure. VMs can rely on HW features to ensure memory isolation.
- tssge 3y ago
  Containers share the host kernel, thus the attack surface is as large as the kernel functionality that is exported to the container by the host (usually almost all syscalls). In VMs as far as I know the attack surface is much smaller as the interaction between the guest and host kernel is limited.
- Syonyk 3y ago
  Containers rely on the kernel to enforce separation. They're great for keeping trusted workloads from interfering with each other, but I don't trust them for potentially hostile workload separation. If you can compromise the kernel (and kernel exploits aren't particularly expensive nor uncommon), then a container is like a door locked by a sign that says "Please do not open without permission." If you don't care to go through it, you won't. And if you want to get through it, it doesn't stop you. Once you're in the kernel, containers don't offer any meaningful separation. Qubes uses hardware virtualization with a fairly stripped down Xen to provide the isolation, and that's a somewhat harder lock to crack open if you want to transit between silos.
ghgr 3y ago
I highly recommend it. Since I tried it a couple of years ago I can't imagine working without it. Examples of things that I can't imagine doing in any other system: - curl|bash or similar - pip install, npm install etc - run any random github project - sudo install the drivers of my Brother printer - install zoom - plug random cheap USB devices to eg update their firmware In addition to that you can easily restart frozen VMs without restarting the whole system, keep backups of your VMs (very handy when restoring or changing PCs), reinstall some VMs if you mess up, etc. Not suitable is for GPU intensive work, though (although if you have a dedicated GPU in theory you can assign it to a VM).
- JackRumford 3y ago
  Ashamed to say but I do all these things on my main OSs for ~15 years and I never had any problem (IIRC). Yes, I'm not huge on security and I realize what this could do, but I figure the chance is as big as getting it through a channel I don't expect.
  - deleted 3y ago
    [deleted]
ChrisArchitect 3y ago
Anything new from that release a month ago? https://news.ycombinator.com/item?id=36178205 https://news.ycombinator.com/item?id=36178205
syntaxing 3y ago
Whoa is this firefox containers but at an OS level. Can you SSH to each container without using the window environment? I wanted to use something like proxmox but decided not to because my computer was only 4 cores and 4 threads. If I can use this but "dynamically" allocate the CPUs, it would be perfect for my application.
- fsflover 3y ago
  You can't ssh into the Qubes VMs from dom0. It would break the security model. You do not run anything in dom0 at all. But you can create an AdminVM that manages other VMs.
  - onetuser 3y ago
    I doubt ssh or simple sh is a matter in this case. You can do simple sh: qvm-run --pass-io {VM_name} -- ls Security model is not to do anything non-admin related from dom0: if you "own" dom0 you can do everything. Allocating amount of CPU cores is a feature of VM. Not sure about dynamic though. There is dynamic flag about memory, not CPU. In practice it looks like CPU is shared among all VMs, no need of special flag for it.
Dah00n 3y ago
Neither of my AM5 motherboards will allow QubesOS to install with Secure Boot on (and it's not going to be turned off) which really annoys me as I want to use it.
- ThePowerOfFuet 3y ago
  The installer is likely not signed in a way Secure Boot trusts it. Verify the ISO yourself with the PGP key, disable Secure Boot, install it, re-enable Secure Boot.
chrisnight 3y ago
I personally daily drove QubesOS for about half a year when in school, and personally, I loved it. When I first tried it out, I fully expected it to be a nightmare to use, given that's how it's usually advertised by non-users. But in using it, I really enjoyed its workflow and the seamless compartmentalization of applications on a computer. Program isolation is honestly a feature that other distros should use more often. The idea that programs can only access networks, USB devices, files, and X windows of programs that it's been explicitly let to access is an extremely useful tool that isn't just for people who are worried about government surveillance. I personally enjoyed having about 5 different Firefox apps that each led to their own VM with its own files, browser history, cookies, and extensions, and even networks that automatically put traffic through a VPN at times. Chrooting and Firefox profiles only help so much, if you can even set them up to be as seamless as Qubes. I'm of course not getting into the security benefits and all that of Qubes, but its where I feel a lot of people don't realize the benefits of an OS like this. The workflow improvement is just as inspiring as the security improvement from the system.
- r2p2 3y ago
  Sounds like you abandoned it after half a year? Would you mind to elaborate on the reason (s)?
  - chrisnight 3y ago
    My laptop broke and I had to buy a new one. The new one was intel 12th gen, which was unsupported at the time. Why haven't I come back to it? I now often use programs that require hardware acceleration for optimal use, which is unsupported by Qubes due it being a potential security issue. If you mainly use your laptop for non-intensive tasks though, I still highly recommend.
dang 3y ago
Related. Others? Qubes OS 4.2-rc1 is available for testing - https://news.ycombinator.com/item?id=36178205 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 https://news.ycombinator.com/item?id=33396604 - Oct 2022 (15 comments) What Is Qubes OS? - https://news.ycombinator.com/item?id=32036899 https://news.ycombinator.com/item?id=32036899 - July 2022 (82 comments) Qubes OS: A reasonably secure operating system - https://news.ycombinator.com/item?id=30776103 https://news.ycombinator.com/item?id=30776103 - March 2022 (97 comments) Qubes OS 4.1.0 has been released - https://news.ycombinator.com/item?id=30215210 https://news.ycombinator.com/item?id=30215210 - Feb 2022 (1 comment) Ask HN: Qubes OS or just separate VMs for separating work and private files? - https://news.ycombinator.com/item?id=29537961 https://news.ycombinator.com/item?id=29537961 - Dec 2021 (6 comments) Qubes OS 4.1-rc1 has been released - https://news.ycombinator.com/item?id=28856957 https://news.ycombinator.com/item?id=28856957 - Oct 2021 (5 comments) Qubes OS 4.0 has been released - https://news.ycombinator.com/item?id=16699900 https://news.ycombinator.com/item?id=16699900 - March 2018 (39 comments) Qubes OS: A reasonably secure operating system - https://news.ycombinator.com/item?id=15734416 https://news.ycombinator.com/item?id=15734416 - Nov 2017 (144 comments) Reasonably Secure Computing in the Decentralized World - https://news.ycombinator.com/item?id=15566563 https://news.ycombinator.com/item?id=15566563 - Oct 2017 (44 comments) Toward a Reasonably Secure Laptop - https://news.ycombinator.com/item?id=14743238 https://news.ycombinator.com/item?id=14743238 - July 2017 (100 comments) “Paranoid Mode” Compromise Recovery on Qubes OS - https://news.ycombinator.com/item?id=14218504 https://news.ycombinator.com/item?id=14218504 - April 2017 (14 comments) Qubes OS Begins Commercialization and Community Funding Efforts - https://news.ycombinator.com/item?id=13069615 https://news.ycombinator.com/item?id=13069615 - Nov 2016 (24 comments) Qubes OS 3.2 has been released - https://news.ycombinator.com/item?id=12604417 https://news.ycombinator.com/item?id=12604417 - Sept 2016 (30 comments) Security challenges for the Qubes build process - https://news.ycombinator.com/item?id=11801093 https://news.ycombinator.com/item?id=11801093 - May 2016 (17 comments) Qubes OS 3.1 has been released - https://news.ycombinator.com/item?id=11260857 https://news.ycombinator.com/item?id=11260857 - March 2016 (44 comments) Converting untrusted PDFs into trusted ones: The Qubes Way (2013) - https://news.ycombinator.com/item?id=10538888 https://news.ycombinator.com/item?id=10538888 - Nov 2015 (5 comments) Intel x86 considered harmful – survey of attacks against x86 over last 10 years - https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 - Oct 2015 (169 comments) Qubes – Secure Desktop OS Using Security by Compartmentalization - https://news.ycombinator.com/item?id=8428453 https://news.ycombinator.com/item?id=8428453 - Oct 2014 (49 comments) Introducing Qubes 1.0 ("a stable and reasonably secure desktop OS") - https://news.ycombinator.com/item?id=4472403 https://news.ycombinator.com/item?id=4472403 - Sept 2012 (59 comments) Qubes: an open source OS with strong security for desktop computing - https://news.ycombinator.com/item?id=2645170 https://news.ycombinator.com/item?id=2645170 - June 2011 (16 comments) Review: Qubes OS Beta 1 — a new and refreshing approach to system security - https://news.ycombinator.com/item?id=2504274 https://news.ycombinator.com/item?id=2504274 - May 2011 (1 comment) The Linux Security Circus: On GUI isolation - https://news.ycombinator.com/item?id=2477667 https://news.ycombinator.com/item?id=2477667 - April 2011 (47 comments) Qubes Beta 1 has been released (strong desktop security OS) - https://news.ycombinator.com/item?id=2439096 https://news.ycombinator.com/item?id=2439096 - April 2011 (3 comments) Qubes Architecture - actual security-oriented OS - https://news.ycombinator.com/item?id=1796384 https://news.ycombinator.com/item?id=1796384 - Oct 2010 (1 comment) Open source Qubes OS is ultra secure - https://news.ycombinator.com/item?id=1249857 https://news.ycombinator.com/item?id=1249857 - April 2010 (7 comments) Introducing Qubes OS - https://news.ycombinator.com/item?id=1246990 https://news.ycombinator.com/item?id=1246990 - April 2010 (20 comments)
snvzz 3y ago
QubesOS is amazing, with a lot of interesting concepts. While its dependency on Xen, a fairly bloated and thus unsafe hypervisor, is unfortunate, there's an effort[0] to remake Qubes around seL4. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
nasc_ 3y ago
I'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 essentially a fresh linux install. It's easier to stay on task when each VM is designed to only do one kind of task. It's also nice having debian, fedora, windows, kali, and whonix all easily accessible on the same machine. The main sticking point for me is that Qubes is reasonably secure from _myself_. I make mistakes. I first started using linux with an Ubuntu install that I broke a year later because I accidentally added in a space when typing `rm -rf ~/Arduino` which made it `rm -rf ~ /Arduino`. On Qubes I can `sudo rm -rf /` on the VM I'm using right now and not break a sweat. I have a keybind to spawn a disposable "airgapped" VM to deal with sensitive or untrusted data, and it helps knowing that even if I mess up with whatever I'm doing, the VM will keep everything reasonably contained. Some cool things that Qubes has outside of just VMs are its features enabled by the communication between VMs. Notable ones are Split GPG (https://www.qubes-os.org/doc/split-gpg/ https://www.qubes-os.org/doc/split-gpg/) which let you use a VM as if it were a smartcard for GPG and Split SSH (https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md https://github.com/Qubes-Community/Contents/blob/master/docs...) which let you isolate your private SSH keys from your VM running your SSH client. There are some sticking points around Qubes. For instance, I use Tailscale to connect my computers to each other from anywhere. Tailscale's install scripts add their keys to my VM's package manager for updates and installs. The proper way to do this in Qubes is to clone a TemplateVM, run Tailscale's install script, update, install, and then base an AppVM off of it. But that creates an entire new OS taking up storage and requiring updates. You can hack a way around this in an AppVM which saves a considerable amount of space, but it takes a lot of upfront time to do and requires you to manually update it. Another sticking point is hardware acceleration. The desktop environment has access to hardware acceleration, so it runs fine, but opening videos in AppVMs is all software decoded. I'm on a Thinkpad T580 and it can run 1080p videos, but the fans turn on and can't do 4K. When I want to game or do something GPU heavy I either stream from my tower or completely switch over. Overall, I'm really happy with Qubes and I'm planning to stick with it on my laptops.
- 3y ago
deleted 3y ago
[deleted]
onetuser 3y ago
I use Qubes because of one exact feature: single Desktop Environment for windows from different Virtual Machines. And AFAIK there are no alternatives. Use it for work, development, personal tasks for about 2 years so far. But it has many restrictions, e.g. gaming is problematic because of this single "main" desktop and trucking cursors bug, recording screen when there are several monitors is bugging and problematic, streaming or working with graphics is problematic, development that requires other virtualization like android (as i heard) is problematic (though docker works, tested). This OS is enough for my tasks, I like concept of separating activities, e.g. when i share desktop on skype, people see only skype's VMs windows. And single Desktop Env is killer feature. But because of many restrictions this OS is definitely not for everyone.
- onetuser 3y ago
  Also remote desktop cannot be done at least by usual means. And this is big No if you need to work remotely sometimes.
  - pph 3y ago
    xfreerdp works just fine, however it requires some fiddling if you want to use it on multiple monitors.
    - onetuser 3y ago
      Is rdp server in dom0 or in VM? Connecting remotely to VM at most i was able to see opened VM's windows, but no keyboard/mouse interaction because dom0 is responsible for it.
- wkat4242 3y ago
  For gaming I would just use a different machine. Trying to use an OS like this for that is always a compromise.
aborsy 3y ago
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.
- ThePowerOfFuet 3y ago
  Standalone (non-Qubes) Whonix runs on Kicksecure; in fact, both projects are from the same author.
pgporada 3y ago
Daily drove qubes for 5.5 years. I liked it a lot.
- fsflover 3y ago
  And what happened then?
  - pgporada 3y ago
    I moved to another team that didn't have a requirement for running Qubes. As soon as I go back, I'll be using Qubes again. Right now I'm on pop_os.
vacuity 3y ago
The 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.
unintendedcons 3y ago
I bought a Librem laptop for Qubes support. Feels like home.
genjii931 3y ago
How is this different than an immutable distro like Fedora Silverblue?
- deleted 3y ago
  [deleted]
plaguepilled 3y ago
Here's the bit that confuses me: no secure boot. QubesOS does a lot of good things, but Secure Boot is sort of a nonnegotiable for a lot of security profiles because its one of the few ways you protect boot. I'd be interested to hear from someone more in the know why they haven't implemented it yet.
- dmm 3y ago
  I think the optional anti-evil maid support includes secure boot: https://www.qubes-os.org/doc/anti-evil-maid/ https://www.qubes-os.org/doc/anti-evil-maid/ > Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks.
  - plaguepilled 3y ago
    That makes much more sense, thanks. Still a bit confusing that its not on by default, but also much more trustable.
    - dmm 3y ago
      In my view the secure boot support provided by mainstream Linux distributions is more about providing installability on systems with secure boot enabled, rather than providing real security benefits. My reasoning is that while the bootloader and the kernel are signed, the initrd image loaded very early on in boot is not, because it is generated on device. So it provides a convenient way to compromise any system you have physical access to. The anti evil maid implementation I linked to attempts to mitigate this hole using a TPM. I'm not sure why it isn't on by default but perhaps it's because the implementation has different options that require deciding on a threat model, e.g. setting a TPM password or using an external usb device to store a LUKS key. Here's a good blog post about the anti evil maid implementation that qubes uses(it also works with other distros like Fedora): https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.h... This blog post contains a good overview of the secure boot status quo along with another potential future fix: https://0pointer.net/blog/brave-new-trusted-boot-world.html https://0pointer.net/blog/brave-new-trusted-boot-world.html

176 points by TheFreim 3y ago

this is my next OS to experiment with. However i'm worried my toy laptop with 16gb of ram (thinkpad t480) wont cut it. Anyone want to chime in here?

polotics 3y ago
16GB of RAM is adequate for Qubes, in practice you end up running a handful of Xen VMs, with most of the VMs (vault, disposable,...) using little RAM.
- mdp2021 3y ago
  The system requirements are specified as: minimum 6GB RAM; 16GB recommended https://www.qubes-os.org/doc/system-requirements/ https://www.qubes-os.org/doc/system-requirements/
Forbo 3y ago
Last time I tried to throw it on an old box it couldn't handle it due to the lack of IOMMU. Granted this was like... 5 or so years ago? I think my newer laptop could probably handle it, so maybe it would be worth giving another shot.
- Syonyk 3y ago
  There are ways to get it running without an IOMMU, mostly involving making your NetVM and such paravirtualized. You just lose basically all of the hardware isolation benefits there. But for playing around, especially on a trusted LAN, you should be able to get it working. If you can't figure it out, jump on the IRC channel - there are a few people in there pretty good at weird hardware hacking for Qubes.
weinzierl 3y ago
I used it productively (see my other comment) a couple of years a ago on an average Dell Inspiron. It worked pretty well, no complaints.
jamal-kumar 3y ago
I've used this as my daily driver before when my workflow needed more crossplatform operability between windows and different varieties of linux. This was a long while ago on some old 2013 laptop with 16 gigs of ram and it worked fine. The real thing you gotta watch out for is full compatibility with all the virtualization extensions it needs in the processor. Key in that old laptop working was that it was an i7.
Syonyk 3y ago
It's fine for light to moderate use, just don't expect to run a ton of AppVMs at once. I've got an X250 (2C/4T) 16GB gutless wonder as my Qubes laptop, and it's fine. Qubes has memory balancing/clawback from VMs, so you can in practice have more AppVMs open than you'd expect - they'll be using less RAM, but it works. If you're on a short-RAM laptop, though, definitely reduce Dom0's memory allocation. It defaults to 4GB, and you're perfectly fine with 2GB or perhaps even 1GB - there's not much going on in it, and that RAM is better used for AppVMs. If you're short on cores, you might also look at the "sched-gran=core" flag to Xen. This allows hyperthreading, but ensures that hyperthreads are only ever scheduled in the same VM (and as the threat model assumes "anything in a VM can read anything else in a VM," a hyperthread-based leak doesn't gain an attacker any access you wouldn't otherwise have). The performance gains on a laptop can be noticeable. Don't expect great battery life, though. Xen's power management is "present and accounted for," at best. There's also an incantation to disable turbo that helps a lot when mobile.
hiatus 3y ago
Runs fine on my framework laptop with 16gb of ram.
nasc_ 3y ago
I've been daily driving it on my Thinkpad T580 with 16gb of ram for the past two years. I really enjoy it. Very occasionally it tells me that it's running out of RAM, but when that happens it's usually because I forgot to shutdown some VMs. Besides for that everything works great. I'd recommend using an SSD though with at least 512GB of storage, but better with 1TB.

weinzierl 3y ago

I 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. With Qubes it is convenient too. I used Qubes to open the application mails and their attachments and converted the interesting ones to trusted PDFs which I then forwarded to the relevant people. All further communication was only with the trusted versions. [1] https://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html https://blog.invisiblethings.org/2013/02/21/converting-untru...

neodypsis 3y ago
You can use something similar on macOS, Windows or Linux, based on Docker containers, see Dangerzone: https://github.com/freedomofpress/dangerzone https://github.com/freedomofpress/dangerzone
- weinzierl 3y ago
  I didn't know about that but that looks really nice. From a quick glance I understand that they can even utilize OCR to make the trusted PDF into more than an image container. Back in the day when I used Qubes it could not do that. (I haven't used it for a while so I don't know if it can now) I still think security-wise Qubes is a bit better because it relies on VMs instead of containers.
- Syonyk 3y ago
  The problem is that containers rely on the OS kernel to enforce separation, and kernel exploits are an awful lot less rare than anyone would prefer. If someone is delivering targeted malware to a company through HR channels, it's safe to assume that if they can escape the document viewer, they can probably also try for a local root/kernel exploit and escape the container. Containers are separation of convenience - not a hard security boundary.

flashback2199 3y ago

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

frugalmail 3y ago
Double whammy, because sadly you can't run it in a VM either. At least that's my experience.
- Syonyk 3y ago
  If your hypervisor supports nested virtualization, it should work. It'll probably grumble about the lack of IOMMU and various other things, but you should be able to run it in VMWare or KVM, if you're willing to jump through some hoops. Not sure why you'd bother, though. If you're already spinning up VMs, just use that capability. Qubes makes "spinning up a ton of VMs on the iron" a lot easier and more usable.
  - flashback2199 3y ago
    > Not sure why you'd bother Because some software expects to run a VM itself such as Docker Desktop which I said in my original comment.
    - Syonyk 3y ago
      And if you'll note, under your original comment I added some detail on how to enable nested virtualization in Qubes.
      - flashback2199 3y ago
        Replied
  - kj4ips 3y ago
    My understanding is that this is how Qubes itself is tested.

aborsy 3y ago

Is QubesOS used in the security companies or community? I know it’s used in Mullvad, and recommended by Snowden (but he isn’t a security specialist). I have been playing with it, and it might work as a daily driver.

Izmaki 3y ago
It's not often that the benefits QubesOS brings are what security companies (or the community) needs. If you do malware analysis, Windows VMs in isolation on a throw-away laptop is better. If you do penetration testing, Windows or regular Linux will be better, too. If you do extremely sensitive communication you're in a very niche group of people and chances are you're using a provided equipment by your superior (e.g., modified laptops).
- anonym29 3y ago
  >If you do malware analysis, Windows VMs in isolation on a throw-away laptop is better. >If you do penetration testing, Windows or regular Linux will be better, too. I am going to firmly disagree with these two points. I've been a red teamer at one of the three big cloud providers for over a decade, and a passionate hobbyist with both malware RE and offsec (CTFs, bug bounties, etc). I've reversed easily 2000+ different samples of malware, have more CVEs than I can count (several dozen), and can make my way through a corporate network quicker than almost any known APT group. I use Windows qubes, both as sandboxes and for certain utilities that only run on Windows, and I do pentesting from Linux-based qubes. There is precisely one restriction I face with Qubes in my entire line of work: even with two GPU's installed for isolation purposes, Nvidia GPU's (even with FLReset+) do not like being passed through by Xen. Older AMD cards like my RX 580 work fine. That said, there are only two things I'd have any use out of a GPU for - hash cracking (obvious) and LLM workloads (code generation, to speed up PoC prototyping, tool development, etc). Fortunately, I have access to a six figure rig dedicated to hash cracking at work, as well as effectively unlimited usage of a non-local code generation LLM. There is no circumstance in which running Windows on bare metal is ideal or optimal in any way whatsoever for just about any kind of security work. Linux is better in some ways, but even then, segregating workflows in ring3/userland is a must, and Qubes makes this painless, quick, and easy compared to spinning up a bunch of VMs in your distro of choice. The USP of Qubes isn't that it does anything magic to make a level of security possible that isn't on other platforms, it's how it makes attaining and maintaining that level of security so effortless and seamless compared to other solutions. The only alternative I've played with that comes close (imo) is Subgraph OS, but it's really not an exaggeration to say that project is absolutely still in alpha status of development, and I would not yet rely on that for sensitive workloads. One aspect of what you said that I do agree with and wholeheartedly support is hardware isolation. Even with Qubes, hardware isolation is a fine solution to Xen HV exploits, for the tiny handful that have affected Qubes' Xen implementation.

GoofballJones 3y ago

I hadn't checked on this project in some time, and last I looked it seemed to be stagnant. Good to see it going strong again. I just remember that, hardware wise, there wasn't a lot of things that could run all aspects of the OS and be 100% with it. The "certified hardware" on the site also looks like it's out of date.

fsflover 3y ago
This project was never stagnant, a lot of things are always happening here: https://github.com/QubesOS/qubes-issues/issues https://github.com/QubesOS/qubes-issues/issues. Concerning the certified hardware, few vendors try to make the certification, and also coreboot is required: https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements https://www.qubes-os.org/doc/certified-hardware/#hardware-ce...
eduction 3y ago
It has remained quite active since I started using Qubes in 2016. I think when Joanna left day to day work it's possible things slowed a bit but I didn't have enough context since that wasn't long after I started. Based on hanging out in the support forums it seems like there have been some pretty large groups of new users, honestly I have no idea why many came at once but they did. Of course for a project this small, "large" is relative. The current work includes making dom0 smaller by delegating the gui to a service Qube.

barbariangrunge 3y ago

Anybody here actually use it day to day? Or is this more of a server OS?

beardog 3y ago
See my top level comment about daily driving it.
Zambyte 3y ago
> Or is this more of a server OS? It's specifically designed for desktop use https://www.qubes-os.org/intro/ https://www.qubes-os.org/intro/
Infernal 3y ago
It is explicitly not a server OS, it really only makes sense as a graphical workstation OS.
aborsy 3y ago
It’s meant to be used in a single-user laptop or desktop.
Syonyk 3y ago
Yeah. I started playing with it about 2 years ago, and I now caution people that "it's really a bit virus-like." It went from being on one "play" computer to being my daily driver OS on 4 machines in that time. It's fine. You just have to be willing to operate on a "If I can't do it, then I must not need to do it" sort of basis with things like media. But that's no real problem for me, I hate video anyway.

beardog 3y ago

I love Qubes a lot, I daily drove it for a few years and still have it on a laptop. but i would not recommend it even to most technical people, mainly because you forfeit the ability to run things on bare metal. "dom0" is the same as on normal xen - it is a VM and has the associated overhead still. On top of that, the official Qubes dom0 runs a very outdated fedora version. I am instead writing my own code to automate libvirt to replicate much of Qubes' functionality (ephemeral roots for vms, disposable vm support, GUI isolation) so i can still have Qubes security for most of my apps but fully exercise my hardware when I want. There are also some minor criticisms i have of Qubes' default, mainly that appvms have passwordless sudo by default and less importantly, no MAC such as apparmor. Passwordless sudo arguably makes it somewhat easier to break out of the VM and no in-vm sandboxing means you have to run every in a separate VM unless you want to set that up yourself. For example i don't really want my work thunderbird to have access to my work browser, so a single "work" domain isn't enough for me.

beardog 3y ago
To add, it works quite well if you can accept the caveats of no (easy/default) GPU access (so no gaming). It is not a lot slower if you have enough ram to keep your VMs booted, i mainly noticed a difference in i/o speed but that may have been my particular setup. You aren't meant to mess with dom0 (so also your desktop) much, so ricers won't like it unless they are willing to break the security model somewhat. It is also not meant to be a shared PC. Windows (10) support is pretty mediocre but it does work. I was able to do a WFH job that required windows using it without pain - you don't get seamless windows though.
Syonyk 3y ago
The threat model assumes that any code in a VM can, with some application of effort, access anything else in that VM. Given the relatively low cost of local root exploits and kernel exploits, this is reasonable. Passwordless sudo is simply a reminder that you can't rely on intra-vm separation of anything you care about separating. If you wanted to add additional hardening within a VM, it's supported - create your own templateVM for it, and use it. It's just not the default, and I generally agree with it. If you trust the OS kernel and features to keep things separated, there's no reason to run Qubes in the first place.

legrande 3y ago

What kind of threat model requires someone to use Qubes? I know Snowden uses it and there's even a testimonial of him on the Qubes site recommending it. Is this for people on 'lists' or are high value targets because they visited the wrong site or said something the authorities didn't like and their machines are now being targeted?

beardog 3y ago
Honestly you don't need to be super paranoid to benefit from Qubes. Windows and Linux default sandboxing is still pretty mediocre at best, people can't be perfect with security all the time and sometimes even legit programs get compromised, so the sandboxing security model helps contain the damage. That said you can still setup sandboxing without Qubes.
fsflover 3y ago
I would say, almost anyone running anything untrusted from time to time can benefit from the strong hardware virtualization. Qubes is my daily driver by the way. My attempt of explaining it to a layman: https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15 https://forum.qubes-os.org/t/how-to-pitch-qubes-os/4499/15
- Syonyk 3y ago
  And "anything untrusted" includes "any use of the internet." Browser escapes are cheap enough and common enough that we've seen malware delivered through advertising networks before.
thoughtbag 3y ago
I know what Theo says about (x86) virtualization[1], but I think it's still useful to virtually separate your random browsing the web from things like health and banking, or where you keep your ssh keys (if you don't use a Yubikey or similar to keep it off your laptop) -- or other secrets. You can be a victim of a random drive-by, you don't have to be a person on a "list". [1] https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582

KingMachiavelli 3y ago

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

Levitating 3y ago
I guess adding more variation to QubesOS systems would make it less secure as there is more room for bugs.
coppsilgold 3y ago
There is actually a project which aims to do that: <https://spectrum-os.org https://spectrum-os.org> Unrelated to QubesOS.
Syonyk 3y ago
If you have the skills to port the tools to KVM, please do so. There's a shortage of sufficiently paranoid low level sorts with the time and interest in the hacking on Qubes. Getting it working on ARM is also of interest.
snvzz 3y ago
>For example, it'd be nice to use KVM (QEMU or even crosvm) instead of Xen Or even better, seL4, for which an effort exists[0]. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
vacuity 3y ago
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

DeathArrow 3y ago

>Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called qubes. What's wrong with containers? They are supposed to provide better performance than VMs. Are containers less secure?

vorpalhex 3y ago
Yes. Containers generally assume a non-hostile workload and don't make assurances about certain kinds of tampering.
deleted 3y ago
[deleted]
hiatus 3y ago
Containers rely on the security of the operating system. If you can compromise the system you can potentially compromise your neighbors. VMs rely on the security of the hypervisor.
ahmedalsudani 3y ago
Yes, they are less secure. VMs can rely on HW features to ensure memory isolation.
tssge 3y ago
Containers share the host kernel, thus the attack surface is as large as the kernel functionality that is exported to the container by the host (usually almost all syscalls). In VMs as far as I know the attack surface is much smaller as the interaction between the guest and host kernel is limited.
Syonyk 3y ago
Containers rely on the kernel to enforce separation. They're great for keeping trusted workloads from interfering with each other, but I don't trust them for potentially hostile workload separation. If you can compromise the kernel (and kernel exploits aren't particularly expensive nor uncommon), then a container is like a door locked by a sign that says "Please do not open without permission." If you don't care to go through it, you won't. And if you want to get through it, it doesn't stop you. Once you're in the kernel, containers don't offer any meaningful separation. Qubes uses hardware virtualization with a fairly stripped down Xen to provide the isolation, and that's a somewhat harder lock to crack open if you want to transit between silos.

ghgr 3y ago

I highly recommend it. Since I tried it a couple of years ago I can't imagine working without it. Examples of things that I can't imagine doing in any other system: - curl|bash or similar - pip install, npm install etc - run any random github project - sudo install the drivers of my Brother printer - install zoom - plug random cheap USB devices to eg update their firmware In addition to that you can easily restart frozen VMs without restarting the whole system, keep backups of your VMs (very handy when restoring or changing PCs), reinstall some VMs if you mess up, etc. Not suitable is for GPU intensive work, though (although if you have a dedicated GPU in theory you can assign it to a VM).

JackRumford 3y ago
Ashamed to say but I do all these things on my main OSs for ~15 years and I never had any problem (IIRC). Yes, I'm not huge on security and I realize what this could do, but I figure the chance is as big as getting it through a channel I don't expect.
- deleted 3y ago
  [deleted]

ChrisArchitect 3y ago

Anything new from that release a month ago? https://news.ycombinator.com/item?id=36178205 https://news.ycombinator.com/item?id=36178205

syntaxing 3y ago

Whoa is this firefox containers but at an OS level. Can you SSH to each container without using the window environment? I wanted to use something like proxmox but decided not to because my computer was only 4 cores and 4 threads. If I can use this but "dynamically" allocate the CPUs, it would be perfect for my application.

fsflover 3y ago
You can't ssh into the Qubes VMs from dom0. It would break the security model. You do not run anything in dom0 at all. But you can create an AdminVM that manages other VMs.
- onetuser 3y ago
  I doubt ssh or simple sh is a matter in this case. You can do simple sh: qvm-run --pass-io {VM_name} -- ls Security model is not to do anything non-admin related from dom0: if you "own" dom0 you can do everything. Allocating amount of CPU cores is a feature of VM. Not sure about dynamic though. There is dynamic flag about memory, not CPU. In practice it looks like CPU is shared among all VMs, no need of special flag for it.

Dah00n 3y ago

Neither of my AM5 motherboards will allow QubesOS to install with Secure Boot on (and it's not going to be turned off) which really annoys me as I want to use it.

ThePowerOfFuet 3y ago
The installer is likely not signed in a way Secure Boot trusts it. Verify the ISO yourself with the PGP key, disable Secure Boot, install it, re-enable Secure Boot.

chrisnight 3y ago

I personally daily drove QubesOS for about half a year when in school, and personally, I loved it. When I first tried it out, I fully expected it to be a nightmare to use, given that's how it's usually advertised by non-users. But in using it, I really enjoyed its workflow and the seamless compartmentalization of applications on a computer. Program isolation is honestly a feature that other distros should use more often. The idea that programs can only access networks, USB devices, files, and X windows of programs that it's been explicitly let to access is an extremely useful tool that isn't just for people who are worried about government surveillance. I personally enjoyed having about 5 different Firefox apps that each led to their own VM with its own files, browser history, cookies, and extensions, and even networks that automatically put traffic through a VPN at times. Chrooting and Firefox profiles only help so much, if you can even set them up to be as seamless as Qubes. I'm of course not getting into the security benefits and all that of Qubes, but its where I feel a lot of people don't realize the benefits of an OS like this. The workflow improvement is just as inspiring as the security improvement from the system.

r2p2 3y ago
Sounds like you abandoned it after half a year? Would you mind to elaborate on the reason (s)?
- chrisnight 3y ago
  My laptop broke and I had to buy a new one. The new one was intel 12th gen, which was unsupported at the time. Why haven't I come back to it? I now often use programs that require hardware acceleration for optimal use, which is unsupported by Qubes due it being a potential security issue. If you mainly use your laptop for non-intensive tasks though, I still highly recommend.

dang 3y ago

Related. Others? Qubes OS 4.2-rc1 is available for testing - https://news.ycombinator.com/item?id=36178205 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 https://news.ycombinator.com/item?id=33396604 - Oct 2022 (15 comments) What Is Qubes OS? - https://news.ycombinator.com/item?id=32036899 https://news.ycombinator.com/item?id=32036899 - July 2022 (82 comments) Qubes OS: A reasonably secure operating system - https://news.ycombinator.com/item?id=30776103 https://news.ycombinator.com/item?id=30776103 - March 2022 (97 comments) Qubes OS 4.1.0 has been released - https://news.ycombinator.com/item?id=30215210 https://news.ycombinator.com/item?id=30215210 - Feb 2022 (1 comment) Ask HN: Qubes OS or just separate VMs for separating work and private files? - https://news.ycombinator.com/item?id=29537961 https://news.ycombinator.com/item?id=29537961 - Dec 2021 (6 comments) Qubes OS 4.1-rc1 has been released - https://news.ycombinator.com/item?id=28856957 https://news.ycombinator.com/item?id=28856957 - Oct 2021 (5 comments) Qubes OS 4.0 has been released - https://news.ycombinator.com/item?id=16699900 https://news.ycombinator.com/item?id=16699900 - March 2018 (39 comments) Qubes OS: A reasonably secure operating system - https://news.ycombinator.com/item?id=15734416 https://news.ycombinator.com/item?id=15734416 - Nov 2017 (144 comments) Reasonably Secure Computing in the Decentralized World - https://news.ycombinator.com/item?id=15566563 https://news.ycombinator.com/item?id=15566563 - Oct 2017 (44 comments) Toward a Reasonably Secure Laptop - https://news.ycombinator.com/item?id=14743238 https://news.ycombinator.com/item?id=14743238 - July 2017 (100 comments) “Paranoid Mode” Compromise Recovery on Qubes OS - https://news.ycombinator.com/item?id=14218504 https://news.ycombinator.com/item?id=14218504 - April 2017 (14 comments) Qubes OS Begins Commercialization and Community Funding Efforts - https://news.ycombinator.com/item?id=13069615 https://news.ycombinator.com/item?id=13069615 - Nov 2016 (24 comments) Qubes OS 3.2 has been released - https://news.ycombinator.com/item?id=12604417 https://news.ycombinator.com/item?id=12604417 - Sept 2016 (30 comments) Security challenges for the Qubes build process - https://news.ycombinator.com/item?id=11801093 https://news.ycombinator.com/item?id=11801093 - May 2016 (17 comments) Qubes OS 3.1 has been released - https://news.ycombinator.com/item?id=11260857 https://news.ycombinator.com/item?id=11260857 - March 2016 (44 comments) Converting untrusted PDFs into trusted ones: The Qubes Way (2013) - https://news.ycombinator.com/item?id=10538888 https://news.ycombinator.com/item?id=10538888 - Nov 2015 (5 comments) Intel x86 considered harmful – survey of attacks against x86 over last 10 years - https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 - Oct 2015 (169 comments) Qubes – Secure Desktop OS Using Security by Compartmentalization - https://news.ycombinator.com/item?id=8428453 https://news.ycombinator.com/item?id=8428453 - Oct 2014 (49 comments) Introducing Qubes 1.0 ("a stable and reasonably secure desktop OS") - https://news.ycombinator.com/item?id=4472403 https://news.ycombinator.com/item?id=4472403 - Sept 2012 (59 comments) Qubes: an open source OS with strong security for desktop computing - https://news.ycombinator.com/item?id=2645170 https://news.ycombinator.com/item?id=2645170 - June 2011 (16 comments) Review: Qubes OS Beta 1 — a new and refreshing approach to system security - https://news.ycombinator.com/item?id=2504274 https://news.ycombinator.com/item?id=2504274 - May 2011 (1 comment) The Linux Security Circus: On GUI isolation - https://news.ycombinator.com/item?id=2477667 https://news.ycombinator.com/item?id=2477667 - April 2011 (47 comments) Qubes Beta 1 has been released (strong desktop security OS) - https://news.ycombinator.com/item?id=2439096 https://news.ycombinator.com/item?id=2439096 - April 2011 (3 comments) Qubes Architecture - actual security-oriented OS - https://news.ycombinator.com/item?id=1796384 https://news.ycombinator.com/item?id=1796384 - Oct 2010 (1 comment) Open source Qubes OS is ultra secure - https://news.ycombinator.com/item?id=1249857 https://news.ycombinator.com/item?id=1249857 - April 2010 (7 comments) Introducing Qubes OS - https://news.ycombinator.com/item?id=1246990 https://news.ycombinator.com/item?id=1246990 - April 2010 (20 comments)

snvzz 3y ago

QubesOS is amazing, with a lot of interesting concepts. While its dependency on Xen, a fairly bloated and thus unsafe hypervisor, is unfortunate, there's an effort[0] to remake Qubes around seL4. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea

nasc_ 3y ago

I'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 essentially a fresh linux install. It's easier to stay on task when each VM is designed to only do one kind of task. It's also nice having debian, fedora, windows, kali, and whonix all easily accessible on the same machine. The main sticking point for me is that Qubes is reasonably secure from _myself_. I make mistakes. I first started using linux with an Ubuntu install that I broke a year later because I accidentally added in a space when typing `rm -rf ~/Arduino` which made it `rm -rf ~ /Arduino`. On Qubes I can `sudo rm -rf /` on the VM I'm using right now and not break a sweat. I have a keybind to spawn a disposable "airgapped" VM to deal with sensitive or untrusted data, and it helps knowing that even if I mess up with whatever I'm doing, the VM will keep everything reasonably contained. Some cool things that Qubes has outside of just VMs are its features enabled by the communication between VMs. Notable ones are Split GPG (https://www.qubes-os.org/doc/split-gpg/ https://www.qubes-os.org/doc/split-gpg/) which let you use a VM as if it were a smartcard for GPG and Split SSH (https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/split-ssh.md https://github.com/Qubes-Community/Contents/blob/master/docs...) which let you isolate your private SSH keys from your VM running your SSH client. There are some sticking points around Qubes. For instance, I use Tailscale to connect my computers to each other from anywhere. Tailscale's install scripts add their keys to my VM's package manager for updates and installs. The proper way to do this in Qubes is to clone a TemplateVM, run Tailscale's install script, update, install, and then base an AppVM off of it. But that creates an entire new OS taking up storage and requiring updates. You can hack a way around this in an AppVM which saves a considerable amount of space, but it takes a lot of upfront time to do and requires you to manually update it. Another sticking point is hardware acceleration. The desktop environment has access to hardware acceleration, so it runs fine, but opening videos in AppVMs is all software decoded. I'm on a Thinkpad T580 and it can run 1080p videos, but the fans turn on and can't do 4K. When I want to game or do something GPU heavy I either stream from my tower or completely switch over. Overall, I'm really happy with Qubes and I'm planning to stick with it on my laptops.

3y ago

deleted 3y ago

[deleted]

onetuser 3y ago

I use Qubes because of one exact feature: single Desktop Environment for windows from different Virtual Machines. And AFAIK there are no alternatives. Use it for work, development, personal tasks for about 2 years so far. But it has many restrictions, e.g. gaming is problematic because of this single "main" desktop and trucking cursors bug, recording screen when there are several monitors is bugging and problematic, streaming or working with graphics is problematic, development that requires other virtualization like android (as i heard) is problematic (though docker works, tested). This OS is enough for my tasks, I like concept of separating activities, e.g. when i share desktop on skype, people see only skype's VMs windows. And single Desktop Env is killer feature. But because of many restrictions this OS is definitely not for everyone.

onetuser 3y ago
Also remote desktop cannot be done at least by usual means. And this is big No if you need to work remotely sometimes.
- pph 3y ago
  xfreerdp works just fine, however it requires some fiddling if you want to use it on multiple monitors.
  - onetuser 3y ago
    Is rdp server in dom0 or in VM? Connecting remotely to VM at most i was able to see opened VM's windows, but no keyboard/mouse interaction because dom0 is responsible for it.
wkat4242 3y ago
For gaming I would just use a different machine. Trying to use an OS like this for that is always a compromise.

aborsy 3y ago

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.

ThePowerOfFuet 3y ago
Standalone (non-Qubes) Whonix runs on Kicksecure; in fact, both projects are from the same author.

pgporada 3y ago

Daily drove qubes for 5.5 years. I liked it a lot.

fsflover 3y ago
And what happened then?
- pgporada 3y ago
  I moved to another team that didn't have a requirement for running Qubes. As soon as I go back, I'll be using Qubes again. Right now I'm on pop_os.

vacuity 3y ago

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

unintendedcons 3y ago

I bought a Librem laptop for Qubes support. Feels like home.

genjii931 3y ago

How is this different than an immutable distro like Fedora Silverblue?

deleted 3y ago
[deleted]

plaguepilled 3y ago

Here's the bit that confuses me: no secure boot. QubesOS does a lot of good things, but Secure Boot is sort of a nonnegotiable for a lot of security profiles because its one of the few ways you protect boot. I'd be interested to hear from someone more in the know why they haven't implemented it yet.

dmm 3y ago
I think the optional anti-evil maid support includes secure boot: https://www.qubes-os.org/doc/anti-evil-maid/ https://www.qubes-os.org/doc/anti-evil-maid/ > Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks.
- plaguepilled 3y ago
  That makes much more sense, thanks. Still a bit confusing that its not on by default, but also much more trustable.
  - dmm 3y ago
    In my view the secure boot support provided by mainstream Linux distributions is more about providing installability on systems with secure boot enabled, rather than providing real security benefits. My reasoning is that while the bootloader and the kernel are signed, the initrd image loaded very early on in boot is not, because it is generated on device. So it provides a convenient way to compromise any system you have physical access to. The anti evil maid implementation I linked to attempts to mitigate this hole using a TPM. I'm not sure why it isn't on by default but perhaps it's because the implementation has different options that require deciding on a threat model, e.g. setting a TPM password or using an external usb device to store a LUKS key. Here's a good blog post about the anti evil maid implementation that qubes uses(it also works with other distros like Fedora): https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.h... This blog post contains a good overview of the secure boot status quo along with another potential future fix: https://0pointer.net/blog/brave-new-trusted-boot-world.html https://0pointer.net/blog/brave-new-trusted-boot-world.html