On Saturday, November 12, 2016 at 5:21:18 AM UTC+2, Sec Tester wrote: > So Im still new to Qubes, but after going through a bit of a learning curve, > building & customizing VM's to suit my security needs, I have a few thoughts > on its security. > > Firstly I really love the direction Qubes has taken the future of operating > systems, and its has definitely become my OS of choice. > > HOWEVER, i feel that Qubes OS relies HEAVILY on ONE security mechanism > > Isolation. > > There are 2 ways we can improve security > > 1. But adding layers of protection. > 2. By reducing the attack surface area. > > ==================== > Layers of protection > ==================== > In regards to layers of protection, IMO Qubes only has one. By isolating VM's > if a system is infected, it has to breach that VM & gain access to dom0, > where it then has total control of the system. > > The problem is in the current configuration, there is nothing to stop a > hacker or malicious software from running, manipulating VM system files, or > downloading additional hack tools/scripts to attempt to breach into dom0. > > To basic extra layers of protection missing from Qubes that usually hardens > Linux security are; > Password protected root access on VM's > SELinux or AppArmor. > > I have read Qubes excuse for NOT requiring a password for root access in VM's > https://www.qubes-os.org/doc/vm-sudo/ > > I frankly think saying "its highly unlikely if that person (who could breach > a VM to dom0) couldn't also find a user-to-root escalation in VM" as a very > LAZY justification. > > They have basically said, Elite hackers can gain root, so lets just not even > bother with this foundational layer of security. > > So we have VM's where any script kiddies code can run riot. This to me is > over confidence in VM isolation, and a lax attitude because, hey if your > infected you can just reboot & VM is clean again right? Except the infected > files sitting in the home directory, just waiting to be opened again and run > with root permissions. > > And in the example of a server VM, that system may rarely be rebooted very > often? Infecting the system to infect others that connect to that server. NOT > GOOD. > > From what i've read SELinux isn't running do to some compatibility errors, > and because there is no point when the whole system has root access. Well > lets lock down default VM root access, and lets find a way to make SELinux > work in Qubes VMs & even dom0, or possibly AppArmor. Or maybe we need a > totally new piece of software that is Qubes specific. > > The more layers of security in the system the better. > > ================================ > Reducing the attack surface area > ================================ > Qubes OS through the use of dom0 has reduced the attack surface area of the > kernel, which is good. > > However, where i think Qubes could improve right out of the box, is having > dedicated minimized templates for sys-net & sys-firewall. > > I spent time setting up fedora-23-minimal templates specifically for sys-net, > sys-VPN, banking, email & browsing. I plan to make another for sys-firewall > soon. VM's that have the minimal amount of programs on as possible, reduce > the attack surface, and possible exploits. > > Again SELinux not only adds a layer of protection, it also reduces the attack > surface area vulnerable in the system. > > ================= > Finial suggestion > ================= > I would like to see the option to setup a decoy OS in the installation > procedure, similar to true crypt/Veracrypt. > > These days many countries airport security can force you to turn on your > laptop to be inspected, and while i imagine airport security being very > confused by Qubes haha, It would be nice to not have to show them any secure > files. > > Another approach could be decoy VM's (as opposed to another entire decoy > Qubes OS), that boot into different encrypted VM's depending on the password. > ================== > > I do think the Qubes OS team are doing a great job. And i hope they maintain > a security based focus, and not depend solely on isolation.
I'd also rather see Grsecurity. But if for whatever reason that's not possible, both legally (I think Grsec guys require an all or nothing adoption) or technical (Subgraph guys were complaining about Qubes not being compatible with part of Grsecurity), then at least I hope all the security features being introduced into the Linux kernel in the future from the Kernel Self-Protection project, will be adopted and implemented by default by Qubes. I don't know if this is possible with the new management in Qubes 3.2, but what I'd like to see in the immediate future is the possibility to configure some apps and sandboxes ahead of time - like for DispVMs. For instance, let's say I want to see Chromium in a DispVM. I would like to always open DispVM with Chromium sandboxed by Firejail. I wouldn't want to configure that everytime I open a Dispvm, or any other VM. The argument against this may be "why bother with that when DispVM will be discarded in minutes to hours anyway?" Well, first, I'd like the extra protection even within DispVM. As the op said, you could still get VM-escaping exploits in that root-enabled environment. Second, if I have a Personal VM, and a Work VM, a banking VM, and an Others VM, I'd have to configure Firejail for all of them, too. I'd prefer I'd do it only once. But I guess it wouldn't be THAT much of a hassle if I only had to do it four times once. I'd still prefer to be able to configure it for DispVM, though. Because I'd probably want more than just Firejail configured. So I'd need a way to configure everything so I can use that configuration for all future DispVMs. -- 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 https://groups.google.com/d/msgid/qubes-users/903e3d4a-759e-4fbe-80e6-201d220a5324%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.