From 7097cfa2ac07613c2494268abf6b4a89c9c831fb Mon Sep 17 00:00:00 2001 From: Joanna Rutkowska Date: Thu, 7 Apr 2011 19:38:02 +0200 Subject: [PATCH] Add explanations why we don't isolate root from user in VMs and in Dom0 --- appvm/qubes.sudoers | 45 +++++++++++++++++++++++++++++++++++++++++++++ dom0/qubes.sudoers | 28 ++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) diff --git a/appvm/qubes.sudoers b/appvm/qubes.sudoers index 58411299..8087a90a 100644 --- a/appvm/qubes.sudoers +++ b/appvm/qubes.sudoers @@ -1 +1,46 @@ user ALL=(ALL) NOPASSWD: ALL + +# WTF?! Have you lost your mind?! +# +# In Qubes VMs there is no point in isolating the root account from +# the user account. This is because all the user data are already +# accessible from the user account, so there is no direct benefit for +# the attacker if she could escalate to root (there is even no benefit +# in trying to install some persistent rootkits, as the VM's root +# filesystem modifications are lost upon each start of a VM). +# +# One might argue that some hypothetical attacks against the +# hypervisor or the few daemons/backends in Dom0 (so VM escape +# attacks) most likely would require root access in the VM to trigger +# the attack. +# +# That's true, but mere existence of such a bug in the hypervisor or +# Dom0 that could be exploited by a malicious VM, no matter whether +# requiring user, root, or even kernel access in the VM, would be +# FATAL. In such situation (if there was such a bug in Xen) there +# really is no comforting that: "oh, but the mitigating factor was +# that the attacker needed root in VM!" We're not M$, and we're not +# gonna BS our users that there are mitigating factors in that case, +# and for sure, root/user isolation is not a mitigating factor. +# +# Because, really, if somebody could find and exploit a bug in the Xen +# hypervisor -- so far there have been only one (!) publicly disclosed +# exploitable bug in the Xen hypervisor from a VM, found in 2008, +# incidentally by one of the Qubes developers (RW) -- then it would be +# highly unlikely if that person couldn't also found a user-to-root +# escalation in VM (which as we know from history of UNIX/Linux +# happens all the time). +# +# At the same time allowing for easy user-to-root escalation in a VM +# is simply convenient for users, especially for update installation. +# +# Currently this still doesn't work as expected, because some idotic +# piece of software called PolKit uses own set of policies. We're +# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a +# simple experiment: start 'xinput test' in one xterm, running as +# user, then open some app that uses PolKit and asks for root +# password, e.g. gpk-update-viewer -- observe how all the keystrokes +# with root password you enter into the "secure" PolKit dialog box can +# be seen by the xinput program...) +# +# joanna. diff --git a/dom0/qubes.sudoers b/dom0/qubes.sudoers index 726b0974..43995f12 100644 --- a/dom0/qubes.sudoers +++ b/dom0/qubes.sudoers @@ -1 +1,29 @@ %qubes ALL=(ALL) NOPASSWD: ALL + +# +# What we're saying above basically means: if the attacker got user access in +# Dom0, then you're screwed already, as there are dozens of ways for the +# attacker to escalate to root from user (e.g. via xend). +# +# Even that is not necessary, in fact! As all the VM control actions can be +# done by user -- after all this is why you can easily start/create VMs and +# apps in VMs from GUI -- all that the attacker needs is user access in Dom0. +# +# So, because in Qubes OS, in Dom0, user account is just as sensitive as root +# account, we don't pretend otherwise, and try to make life a bit easier for +# the user allowing for easy escalation (no need to choose and remember a root +# password in Dom0). +# +# This is also why we don't pretend that Qubes OS is a multiuser system -- it +# is not! (for the reasons given above). The assumption is that there is only +# one user that logs into GUI manager: YOU. This is hardly a limiting factor +# these days, when it's not uncommon for a single person to own not one, but +# several computers, which are not shared with others (phone, tablet, laptops). +# We live in a PC-era! :) +# +# This means that the user password you choose during installation servers only +# one purpose: it allows you to lock your screen while you're away via the +# screen saver. Nothing more! +# +# joanna. +#