> 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 risks. Cheers. JJ -- 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 email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/658ef4d3ad89a3b9db896d1ff6fa27a0.webmail%40localhost. For more options, visit https://groups.google.com/d/optout.