[HN Gopher] QubesOS - A reasonably secure operating system
___________________________________________________________________
QubesOS - A reasonably secure operating system
Author : TheFreim
Score : 103 points
Date : 2023-07-11 18:11 UTC (4 hours ago)
(HTM) web link (www.qubes-os.org)
(TXT) w3m dump (www.qubes-os.org)
| barbariangrunge wrote:
| Anybody here actually use it day to day? Or is this more of a
| server OS?
| beardog wrote:
| See my top level comment about daily driving it.
| Zambyte wrote:
| > Or is this more of a server OS?
|
| It's specifically designed for desktop use
|
| https://www.qubes-os.org/intro/
| Infernal wrote:
| It is explicitly not a server OS, it really only makes sense as
| a graphical workstation OS.
| aborsy wrote:
| It's meant to be used in a single-user laptop or desktop.
| Syonyk wrote:
| 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 wrote:
| 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.
| Syonyk wrote:
| 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.
| beardog wrote:
| >If you trust the OS kernel and features to keep things
| separated, there's no reason to run Qubes in the first place.
|
| Yeah i see the argument - thats why I would still call Qubes
| very secure as is - but i personally prefer defense in depth.
| Mainly it would be helpful on machines with limited ram that
| can only run a few domains at once.
| beardog wrote:
| 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.
| fsflover wrote:
| > the official Qubes dom0 runs a very outdated fedora version
|
| Why does it matter? You do not run anything in dom0:
| https://www.qubes-os.org/doc/supported-releases/#note-on-dom...
| eduction wrote:
| What do you personally want to run on bare metal? I've been
| using Qubes for 7 years and the only thing I've missed is
| running MAME since Qubes doesn't do nested virtualization. But
| I do everything else I need on there - software dev, office
| productivity, web browsing, email, video transcoding, Spotify
| etc etc. It's rare I would ever need bare metal. (I'm not a PC
| gamer though...)
| weinzierl wrote:
| 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-
| untru...
| neodypsis wrote:
| You can use something similar on macOS, Windows or Linux, based
| on Docker containers, see Dangerzone:
| https://github.com/freedomofpress/dangerzone
| weinzierl wrote:
| 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 wrote:
| 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.
| davidandgoliath wrote:
| And container escape exploits are getting burned by sending
| them out via email? Doubtful.
| Syonyk wrote:
| It depends on who you're targeting and what you want.
|
| But the history of computers security can largely be
| summed as:
|
| "What? You're just paranoid. Nobody would possibly X!"
|
| Someone gets their asses handed to them by someone Xing.
|
| "What? Why didn't you tell us X was a risk we needed to
| be concerned about???"
|
| Iterate.
| chrisnight wrote:
| 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 wrote:
| Sounds like you abandoned it after half a year? Would you mind
| to elaborate on the reason (s)?
| chrisnight wrote:
| 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.
| legrande wrote:
| 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?
| vitehozonage wrote:
| I'd say everyone that has the ability to use it. Society is in
| a dark age where basically nothing else is fit for use; one bad
| click on most machines could compromise you for years, it is an
| insane situation. Even if you have other needs that can't be
| fulfilled with Qubes, you should have a Qubes machine for other
| tasks that are security-sensitive
| Syonyk wrote:
| > _What kind of threat model requires someone to use Qubes?_
|
| "Not trusting modern software to be correct nor secure" is
| sufficient.
|
| I do almost all my web browsing in disposable VMs with no
| access to interesting things like my password manager, email,
| SSH keys, etc. I also run JITless (disable Javascript JIT
| engine), because those are a common attack point on browsers.
|
| If you compromise my browser from a random site, you get
| nothing of interest. Even if you pop the kernel. You still have
| to get through Xen to get to anything I consider of value.
| snvzz wrote:
| >You still have to get through Xen to get to anything I
| consider of value.
|
| It's not unthinkable, as Xen is huge, at hundreds of kLoCs.
| But there's an effort[0] to make a Qubes that uses seL4 in
| place of Xen.
|
| 0. https://trustworthy.systems/projects/TS/makatea
| aborsy wrote:
| Browsers have built-in sandboxes, plus sometimes wrapped
| around stuff like snap.
| Syonyk wrote:
| And yet...
|
| Browser exploits are a thing, and reliably compromise
| systems. Apple just released a security update yesterday
| for "something in WebKit," and we see regular browser
| security updates.
|
| The art of escaping browser sandboxes seems to exceed the
| art of building browser sandboxes. The Javascript JIT
| engine gains you a lot of attack surface, unfortunately
| (one of the reasons I run JITless with Javascript).
|
| As for snaps, they're just containers - kernel separated.
| Unfortunately, I consider the value of that against
| actively malicious code to be "about zero" - local
| root/kernel exploits are fairly cheap. Containers (so
| snaps) are great for _convenience_ - if you want to run
| code you trust without worrying about dependencies, this is
| fine. They 're not fine if you want to isolate things you
| don't trust - such as a browser from "everything else."
|
| Qubes gives you a much harder boundary around your VMs than
| containers and sandboxes do.
| aborsy wrote:
| Snap uses AppArmor, while flatpak uses bubblewrap. You
| need to have a zero day in these sandboxes, in addition
| to in the browser. Not so easy!
|
| But definitely VMs provide a much better boundary.
| beardog wrote:
| 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 wrote:
| 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
| Syonyk wrote:
| 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 wrote:
| 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
| Syonyk wrote:
| Yeah. He's probably right. When we first saw
| Meltdown/Spectre/etc, and he preemtively disabled
| hyperthreading out of an abundance of paranoia, turned out he
| was right...
|
| It's all broken, all the way down. However, compromising a
| browser or kernel is still a lot easier than compromising a
| hypervisor. At least in terms of number of known exploits.
|
| Qubes tends to make very limited use of the riskier parts of
| Xen anyway, though. A lot of the security notices for Xen
| don't apply to Qubes because of how they've configured things
| or what features they use.
| snvzz wrote:
| There's also Makatea[0], an effort to build a Qubes-like
| around seL4.
|
| 0. https://trustworthy.systems/projects/TS/makatea
| thoughtbag wrote:
| He's been right more times that I can count. Abrasive guy
| for sure, but he has decided not to suffer idiots. And he
| does what he does for himself; we are lucky beneficiaries.
|
| Agree wrt your arguments; it's also why I write this in a
| browser in a VM that is not used for anything else than
| this sort of thing, and periodically I will roll back to a
| recent snap shot with a clean browser.
|
| (I do not use Qubes, but I do like their work.)
| weinzierl wrote:
| I used it for sifting through job applications (see my other
| comment).
|
| I think it was worth it because even though we were a small
| boring company we received a fair share of drag-net style
| malware via the application channels.
|
| Some of the attempts were pretty good also. I used to joke that
| the bad guys tailor their cover letters better than most real
| applicants. Which of course is a bit of a hyperbole, but there
| is a kernel of truth. It's not too hard to write a believable
| application letter that fits the archetypal IT position.
| Similar to not all fishing mails being full of spelling errors
| malicious application letters aren't either.
|
| I don't know if we ever received a targeted attack, but I
| wouldn't know. I think bigger companies certainly will and I
| can only consider every HR department a high risk area.
| aborsy wrote:
| 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.
| syntaxing wrote:
| 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.
| Dah00n wrote:
| 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.
| snvzz wrote:
| 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
| sigmonsays wrote:
| 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 wrote:
| 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 wrote:
| The system requirements are specified as:
|
| minimum 6GB RAM; 16GB recommended
|
| https://www.qubes-os.org/doc/system-requirements/
| nasc_ wrote:
| 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.
| Forbo wrote:
| 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 wrote:
| 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.
| Syonyk wrote:
| 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.
| jamal-kumar wrote:
| 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.
| weinzierl wrote:
| 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.
| hiatus wrote:
| Runs fine on my framework laptop with 16gb of ram.
| KingMachiavelli wrote:
| 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.
| coppsilgold wrote:
| There is actually a project which aims to do that:
| <https://spectrum-os.org>
|
| Unrelated to QubesOS.
| snvzz wrote:
| >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
| Levitating wrote:
| I guess adding more variation to QubesOS systems would make it
| less secure as there is more room for bugs.
| Syonyk wrote:
| 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.
| flashback2199 wrote:
| 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.
| yankput wrote:
| 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 the default daemon so, eh. whatever. maybe I'm wrong. there
| are reasons I guess
| flashback2199 wrote:
| It's a good question - docker doesn't require a VM on Linux,
| but Docker Desktop does. I assume it's to make it basically
| the same experience as on Docker Desktop on Windows and
| macOS, but I'm not totally sure. You can install docker the
| same way one would on a server in a qube in QubesOS and it
| works fine, I think I tried that once just to be sure, I just
| wanted to be able to have Docker Desktop. I also didn't want
| to paint myself into a corner in case I should need to run
| something else that also expects to be able to run a VM.
| frugalmail wrote:
| Double whammy, because sadly you can't run it in a VM either.
| At least that's my experience.
| Syonyk wrote:
| 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.
| kj4ips wrote:
| My understanding is that this is how Qubes itself is
| tested.
| flashback2199 wrote:
| > 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 wrote:
| And if you'll note, under your original comment I added
| some detail on how to enable nested virtualization in
| Qubes.
| flashback2199 wrote:
| Replied
| [deleted]
| legrande wrote:
| > nested virtualization
|
| Such abstraction is very unstable. You can always VNC into a
| machine from a browser though, so 'vmception' can be achieved.
| Syonyk wrote:
| You _can._ It 's just neither recommended nor enabled by
| default.
|
| https://forum.qubes-os.org/t/nested-virtualization/14790
|
| Poke around /etc/libvirt/libxl and your particular VM's config
| file. You'll find some lines like:
|
| <feature name='vmx' policy='disable'/> <feature name='svm'
| policy='disable'/>
|
| Enable it, and you should have working nested virtualization.
| flashback2199 wrote:
| I did that very thing about a year ago when I still had
| QubesOS installed, and it did not work. There seems to be a
| lot of misinformation about this swirling around the web. It
| simply does not work. There is a post somewhere that confirms
| it but I don't have the link. Unless the QubesOS
| devs/maintainers made a 180 degree turn since I tried it and
| decided to start compiling QubesOS with xen nested
| virtualization enabled, but I doubt it because their reason
| was that xen's nested virtualization feature is basically
| broken anyway.
| flashback2199 wrote:
| Shoot, as soon as I hit reply some neurons lit up and now I
| remember I was actually able to enable nested virtualization
| in QubesOS, and the relevant options in the VirtualBox
| preferences inside a qube became enabled once I did that, but
| whenever I tried booting any VM the whole system hanged. The
| same system and BIOS settings worked in Ubuntu to boot a
| nested VM in VirtualBox, so I think I had the BIOS settings
| correct. Anyhow, it seemed like a dead-end, so I abandoned
| it.
| Syonyk wrote:
| I'll have to look at it more. I mostly use AMD systems
| these days, which don't support nested virt in Xen, as I
| understand it, but it looks like it should work on Intel.
| flashback2199 wrote:
| I was on Intel when I tried. No worries though, not
| really planning on trying it again.
| hiatus wrote:
| A qube _is_ a VM though, no? So if you wanted to create a VM,
| you can create a QubesOS template and instantiate that?
| flashback2199 wrote:
| Let me know how it works for you
| haswell wrote:
| Not a Qubes user, just a curious reader; what is the issue
| with this? It sounds like you're implying that what parent
| said isn't practical. I'm curious why?
| flashback2199 wrote:
| The issue with trying to hack Docker Desktop and similar
| tools to boot a qube instead of a VM and somehow hack
| QubesOS to not isolate those qubes from each other seems
| self-evident to me and I don't care to explain further.
| aborsy wrote:
| 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 wrote:
| 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 wrote:
| >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.
| fsflover wrote:
| https://forum.qubes-os.org/t/deployments-of-qubes-by-entitie...
| DeathArrow wrote:
| >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?
| thewataccount wrote:
| The way I recommend thinking about it is containers work as a
| "convenient precaution" -
|
| "dumb scripts" that just copy files/install something, encrypt
| files, etc. will be well contained in a container.
|
| "smart scripts" are more rare - but essentially if you're
| trying to break out of a container you can, container breakout
| methods are not uncommon. These types of malware are usually
| more rare.
|
| So if your threat model is "I want to run this program that I'm
| pretty sure I trust but I'm not 100% certain" then a container
| is most likely fine as a convenient precaution.
|
| But if it's "I want to make sure nothing can break out
| (especially if you're running user's code) and compromise the
| full system" then you want VMs.
|
| With the recent pytorch-nightly compromise in december, AFAIK a
| container would have protected you, just don't assume that will
| always be the case.
|
| EDIT: I wish katacontainers was easier to use and was more
| widely used - I feel like it gives most of the usability
| benefits of containers with the security of VM's which is what
| everyone should really want for most things. VM overhead can be
| pretty small, with under 100ms "boot" time, etc.
| vorpalhex wrote:
| Yes.
|
| Containers generally assume a non-hostile workload and don't
| make assurances about certain kinds of tampering.
| [deleted]
| hiatus wrote:
| 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 wrote:
| Yes, they are less secure. VMs can rely on HW features to
| ensure memory isolation.
| tssge wrote:
| 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 wrote:
| 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.
| Dah00n wrote:
| Does this also count for Proxmox?
| hiatus wrote:
| Proxmox containers are just regular containers.
|
| https://pve.proxmox.com/wiki/Linux_Container
| dragonwriter wrote:
| > They are supposed to provide better performance than VMs. Are
| containers less secure?
|
| Yes, the performance advantage is from less isolation/more
| sharing, and that's also why they are less secure.
| GoofballJones wrote:
| 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 wrote:
| This project was never stagnant, a lot of things are always
| happening here: 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-ce...
| eduction wrote:
| 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.
| dang wrote:
| Related. Others?
|
| _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/item?id=30776103 - March 2022 (97
| comments)
|
| _Qubes OS 4.1.0 has been released_ -
| 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 -
| Dec 2021 (6 comments)
|
| _Qubes OS 4.1-rc1 has been released_ -
| 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 - March 2018 (39
| comments)
|
| _Qubes OS: A reasonably secure operating system_ -
| 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 - Oct 2017 (44
| comments)
|
| _Toward a Reasonably Secure Laptop_ -
| 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 - April 2017 (14
| comments)
|
| _Qubes OS Begins Commercialization and Community Funding
| Efforts_ - 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 - Sept 2016 (30
| comments)
|
| _Security challenges for the Qubes build process_ -
| 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 - March 2016 (44
| comments)
|
| _Converting untrusted PDFs into trusted ones: The Qubes Way
| (2013)_ - https://news.ycombinator.com/item?id=10538888 - Nov
| 2015 (5 comments)
|
| _Qubes - Secure Desktop OS Using Security by
| Compartmentalization_ -
| 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 - Sept 2012
| (59 comments)
|
| _Qubes: an open source OS with strong security for desktop
| computing_ - 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 -
| May 2011 (1 comment)
|
| _The Linux Security Circus: On GUI isolation_ -
| 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 - April 2011 (3
| comments)
|
| _Qubes Architecture - actual security-oriented OS_ -
| 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 - April 2010 (7
| comments)
|
| _Introducing Qubes OS_ -
| https://news.ycombinator.com/item?id=1246990 - April 2010 (20
| comments)
| ghgr wrote:
| 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).
| nasc_ wrote:
| 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/) 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...)
| 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.
| [deleted]
| ChrisArchitect wrote:
| Anything new from that release a month ago?
|
| https://news.ycombinator.com/item?id=36178205
| onetuser wrote:
| 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 wrote:
| Also remote desktop cannot be done at least by usual means. And
| this is big No if you need to work remotely sometimes.
___________________________________________________________________
(page generated 2023-07-11 23:01 UTC)