Fixing Whonix boot issue after securing Qubes root auth

tasket · November 17, 2016, 10:53am

Using the vpn-sudo doc, I’ve been experimenting with securing root access in my Qubes templates. This works OK for Debian, but Whonix templates apparently run some boot scripts as regular user interspersed with a few ‘sudo’ commands. The result is that Whonix VMs don’t start cleanly because the Qubes auth prompt pops up a few times.

Instead of relying entirely on an access control tool like apparmor (which I’m also using in Whonix now) I think it would be best to secure the root user as well. So I’d like to propose that we track down and eliminate the use of ‘sudo’ in the Whonix-specific startup scripts.

Chris

Patrick · November 17, 2016, 4:28pm

Unsupported. See my comment here:

https://github.com/QubesOS/qubes-doc/pull/176#issuecomment-242894132

That ticket may also contain information to actually answer your question and someone else who got this solved (I guess) as well.

tasket · November 17, 2016, 9:35pm

Thanks for the link.

I’m interested in this because Qubes security is based on the rationale:

# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- so far there has been only one (!) publicly disclosed
# exploitable bug in the Xen hypervisor from a VM, found in 2008,

(From /etc/sudoers.d/qubes)

Many more than one XSA has washed under the bridge since then, and there are no less than eight coming out on Tuesday!

ITL also ignores the real possibility of having many VMs where less-skilled attackers are running amok and launching attacks on other targets–even if they are contained.

So the hypervisor-only philosophy of Qubes security is wearing thin. If one is going to use a guest OS with all its features and peculiarities, the least one can do is keep its security scheme intact.

tasket · November 18, 2016, 12:07am

BTW, the simplest solution in the near-term is to execute:

cp -a /etc/sudoers.d/power-savings-disable-in-vms /etc/sudoers.d/zz99

…which makes the rule for virt-what command come last.

Patrick · November 18, 2016, 1:11am

Tasket:

I’m interested in this because Qubes security is based on the rationale:
# Because, really, if somebody could find and exploit a bug in the Xen
# hypervisor -- so far there has been only one (!) publicly disclosed
# exploitable bug in the Xen hypervisor from a VM, found in 2008,
(From /etc/sudoers.d/qubes)

Many more than one XSA has washed under the bridge since then, and there are no less than eight coming out on Tuesday!

ITL also ignores the real possibility of having many VMs where less-skilled attackers are running amok and launching attacks on other targets–even if they are contained.

So the hypervisor-only philosophy of Qubes security is wearing thin. If one is going to use a guest OS with all its features and peculiarities, the least one can do is keep its security scheme intact.

Please bring this up at Qubes.

entr0py · November 18, 2016, 6:26am

Chris, I made some of these points in this back-and-forth that starts here: If not going to change the password?

But I thought Marek’s reply on qubes-users was quite convincing:

The point is _if_ someone is able to run arbitrary code as user, he/she
can easily run it also as root, because of tremendous attack surface of
linux kernel and all the services running as root. In the worst case one
needs some patience and simply wait for you to authorize some command to
be ran as root (regardless of authorization method - password, qrexec
confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
anything else).  In the simplest case one may alias 'sudo' to for
example 'sudo /tmp/my-evil-script'.

On the other hand, making it harder to execute arbitrary code in the VM
(reducing attack surface) makes sense. Things like SELinux, AppArmor,
seecomp filters etc.

Certainly, there’s a psychological comfort in clicking off root authorizations. Feels like I’m in control… maybe that peace of mind is worth it even if the security posture is largely unchanged. Guess as long as that comfort doesn’t lead to more risky behavior, no harm done.

tasket · November 18, 2016, 2:58pm

Looking at Marek’s response a second time, I feel like the concern over root is still being short-changed.

No obstacle to root means that malware can persist far more easily after a vulnerability has been patched. This makes Qubes VMs ‘juicy targets’ and negates some of the security bonus that read-only templates provide.
Even if the root prompt isn’t perfect from a psychological standpoint, there are more ways to grant access. It may even be best to set the default to ‘deny’ while setting template VMs to ‘allow’.
The root prompt shouldn’t come up in normal use anyway. Displaying strong language and having “NO” as the default action when hitting Enter should be a substantial improvement in security.

I’ll bring these points up in a new thread on a Qubes list.

tasket · November 18, 2016, 3:01pm

I had one remaining prompt in sys-whonix that didn’t show up when starting the template itself. To resolve it, /etc/sudoers.d/zz99 now contains both these lines:

ALL ALL=NOPASSWD: /usr/sbin/virt-what
ALL ALL=NOPASSWD: /usr/sbin/service whonixcheck *

Patrick · November 18, 2016, 4:22pm

Please check when Whonix 14 testers-only versions are released if any
sudoers entries are missing so these can find their way into the stable
version of Whonix 14.