| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546 |
- 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.
|
