-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
