-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Dec 15, 2021 at 11:25:19PM -0800, Hugus Maximus wrote: > > Hi all, > > I just published document discussing some well known security limitations > of Qubes OS: > > https://www.pentest.es/Demystifying_QubesOS_Security.pdf > > there are some suggestions at the end of the document. I'm aware you have > your own roadmap so I would like to contribute in some design changes that > may be helpful and aligned -not intrusive- with your current architecture. > The first thing I would like to: > > 1) Switch from single user (web browser with root user capabilities) to > multi user. The idea is to hard code a random password and allow sudo only > via Dom0 confirmation
You can configure VM to require dom0 confirmation for sudo access, see: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt At the top of this page you can also find reasoning why it isn't this way by default. There is also obligatory XKCD: https://xkcd.com/1200/ Generally, if someone gets arbitrary code execution inside a VM (outside of any application-specific sandbox, if any), then already has access to most of the stuff that VM has (user data, applications state etc). There is very little point in guarding root access, as it doesn't give you much more. This all is written in the above link already, so I'm not going to repeat it here. But ... > 2) Adding Firejail to default templates. > > 3) Jailing by default the Firefox browser ... having individual applications in additional sandboxes, very much makes sense. That's why we are working on un-breaking SELinux[1], enable Apparmor in Debian[2], (slowly) migrating to Wayland[3] (as otherwise X11 gives trivial bypass of a lot of sandboxes) and few more. Firejail for Firefox makes sense too, although we try to stick with distributions defaults as much as reasonably possible[4] - we let users use Fedora/Debian/etc, not QFedora/QDebian/etc (see reasoning at [4]). But there are exceptions, where we do apply some extra hardening - for example most of the network/firewall configuration is custom. > Having Firejail installed by default on templates will allow to add > new/more apps. > > Also this can open the door to integrate Fireinvoke/Firewarden in the > future so directly opening a a malicious file (like the .tar of my > "Demystifying_QubesOS_Security.pdf" report) can not be a problem anymore in > the future without requiring to open disposable VM's all the time (so, > saving computing resources). Generally, "the qubes way" is to use disposable qubes, but as you (rightfully) noted, it does require resources and isn't always convenient. While in-VM sandboxes are useful defense in depth, I'd rather avoid them being the primary one. Opening a file coming from untrusted world isolated "just" by Linux-based sandbox is not something I'd like to rely on. One of the things we will focus on in short-medium term is to make VMs (especially disposable ones) lighter - both lower RAM usage, and make them quicker to start. This will make more disaggregated setups (like, opening files in disposable qubes by default) less painful to use. As you noted in your article, Qubes provides a lot of tools that can greatly improve user security, but they do rely on the user using them correctly. This is a major obstacle for mass adoption (although probably not the biggest one...). We have some ideas about that (like, providing pre-made configurations for few common tasks, including stricter policies), but this is a tricky trade-off between convenience/flexibility and security. One recent feature that you may find especially interesting, is configuring selected applications to open _all_ files in disposable qubes by default[5]. This a new, experimental thing in Qubes 4.1, and sadly doesn't work with all the applications yet (especially those using dbus-activation). Unfortunately GUI[6] for it didn't make it to R4.1, and the non-GUI method is not documented yet[7]. But the core part is there. I'd like to answer to few points of your article directly too: > The hypervisor domain must NOT be updated/manipulated by the end user (see > below Dom0 design and update strategy) Yes, that's very much on the roadmap. Moving GUI outside of dom0[8] is one of the steps towards this goal. This way, we get rid of the one thing that users like to customize - desktop environment. And removing this massive pile of software from dom0 will make it _much_ smaller, which will make updating as a whole more realistic scenario. Having exactly the same dom0 fs content everywhere will also allow much stricter integrity protection, and verification. > EASY: just forget about doing those operations from the > AppVM/VMs side, just transfer all the responsibility to Dom0. It looks to me > very > feasible to create a file system accessible by both Dom0 and the AppVM where > AppVMs can transfer the files to be manipulated and then execute those actions > from Dom0, not only the confirmation step. No, that's backward. Filesystem-level sharing is rather complex thing, with a huge attack surface, we definitely don't want to expose dom0 to such attacks. When you design your data flow, you (currently, unfortunately) need to think how do you trust components involved. Making transfer trusted->untrusted->trusted slightly(*) less risky is not very useful. If you need such transfer (assuming here you trust the "original" content of downloaded data), simply use appropriate VM to download the file. If in doubt, use (fresh) disposable one. If you don't trust the original content, there are still few things you can do: - for pdf and images, we have tool to "clean" them up[9] - for others, you can always open them in disposable qube, including extracting the data you actually need there (in your very example - open such tar in a disposable qube, and qvm-copy only the content you need - and still treat it as untrusted) (*) Your solution is only about ensuring the file that is sent is the one that got written. But does not cover several other parts: - is correct data actually written (substitute file at download stage, instead of qvm-copy) - is the tool used to preview the file actually showing you really the right content (substitute file at preview stage) and probably few more. > Would anyone kindly give me some hint about were I can start to achieve > this? You can start by checking https://www.qubes-os.org/doc/contributing/. Things like wrapping Firefox (and possibly others) with firejail sounds like a good idea for the start. To keep things nicely organized, IMO it should be a separate repository (and separate rpm/deb/... package). You can use for example https://github.com/QubesOS/qubes-app-linux-snapd-helper as a skeleton. BTW, your appendix A is rather complex, there are much simpler ways. Hint: qvm-run --localcmd. The lack of network in dom0 (and templates) have two purposes: 1. Make it harder to get _into_ dom0. 2. Avoid _accidental_ untrusted data download (like, your favorite desktop configuring tool trying to download you a wallpaper from http://some.random.website/). If you are in dom0 already, your options are rather limitless. Breaking naive connect-back shells is rather poor consolation. [1] https://github.com/QubesOS/qubes-issues/issues/4239 [2] https://github.com/QubesOS/qubes-issues/issues/4088 [3] https://github.com/orgs/QubesOS/projects/5 [4] https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros [5] https://github.com/QubesOS/qubes-issues/issues/6877 [6] https://github.com/QubesOS/qubes-issues/issues/6366#issuecomment-767635670 [7] https://github.com/QubesOS/qubes-issues/issues/7130 [8] https://www.qubes-os.org/news/2020/03/18/gui-domain/ [9] http://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG8B84ACgkQ24/THMrX 1yxjiAf8Day2jC1Mq6i6WVsvUUPe2m3q0e/StY+5QJDSRk7k0RLx9XZYgd85S0NP +eCq7WtRo0KCBidVm8rIl20f3cPzTdORNM2MwaSqcMqy3562NzEXbNJT3mj3lb4O euf1ICMFY+AGnq0SvIkNAszFG0WljfjcxlQpVeHT112hct8hsFhwgFdngbvI/Ueq pFsdHnDFTBbmvkA/x4AjmP+urE5E+z9ZM1KsAuUQx53q/9uXK+vW1IZeiIHGA9Cl jqDsSDAN0YTNii4FldQFBGLlVSUTJcojbM4bW2TtOOLZUDKX21FdcVooB7sARZXz zhzyjWjvUUSKahSiC8nXjo6/lXy0yg== =uvJs -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YbwHzsdq0wRpEced%40mail-itl.
