> Andrew:
> This kind of security-first posture is what has made Qubes famous.

I agree that Qubes separation is probably the most secure basis for a
reasonably usable PC-based platform today.  It's all I'll use.  (I worry
about 4.0 not working on my hardware, tho.  And upgrading hardware brings
its own security risks.)

That being said, there are a few things that stuck out like sore thumbs as
being terribly insecure in the default install, which surprised me:

- (There are some outstanding tickets on this one): All the daemons
started by systemd, some of which phone home (at the very least, leaking
your IP address) to Microsoft (resolving SMB names, even when you don't
use SMB) or RedHat (default network connectivity check for NetworkManger).

exim4, cupsd, ntpd (on by default in debian-8) don't need to be running,
and can potentially leak information (and increase the attack surface). 
pulseaudio and the speaker daemon can potentially leak information from a
VM through audio channels, and aren't needed in most cases.

The default templates should be very much stripped of having any software
run by default, or unexpectedly.  The package (such exim, cups) can be
included in the template, sure, but not on by default.

- Fairly loose default iptables/firewall setup (particularly for outbound
connections).  No inherent DNS leakage protection.  (whonix or a VPN can
solve this.)  Fairly limited firewall configuration.

- No apparmor by default.  When I tried to install it in a VM, I got
errors about a missing kernel module, and haven't explored it further.

Yes, VM separation keeps rogue processes at bay, but it'd still be nice if
a compromised Firefox just didn't have the option of going through
~/Documents and uploading the contents to some .ru site.  :)

Apparmor and its profiles would add this extra layer of protection.  Wow,
being able to run *two* or more apps in a VM without worry of them spying
on each other's data or connect to the net in ways they shouldn't!  :)

Keeping every useful work file on separate or non-networked machines to
avoid rogue applications is too much of a PITA for most people.  Or at
least for me.

- Unencrypted /boot partition.  This one is a huge hole and could be
fixed.  I've converted my /boot to luks filesystem successfully, grub
supports it.  Adding a Grub password doesn't hurt, either.   (As well as a
BIOS password, but I'm digressing.)

- Some of the things trumpeted in the earlier design documents and press
coverage just aren't there.  Sound cards, video cards, storage devices,
USB, all (by default) live in dom0, not safely tucked in VMs.

(Not sure why my network card's Linux module seems to load in dom0 as well
as sys-net, but I'm assuming that's not an issue, and the network card is
fully in sys-net.)

Individual VM's disks aren't encrypted with their own luks filesystem and
keys, which is mentioned in a few articles or papers I read.  Not sure how
important this one is, but where it is listed as a feature in some
reviews, I thought I'd mention it for clarity.  It might be useful if
someone compromised root, that they wouldn't necessarily have access to
the data on your VM's.  But that's a lot more password juggling and
layered encryption with associated CPU cost, so I dunno.  (Qubes VM
Manager would end up being a bit of a password vault in itself, ugh.)

I'm only pointing these out in a constructive way, I still love the
system, and just want to suggest ways to make it even better for those who
don't spend the time or have the knowledge to tweak up these security



You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to