qubes.sudoers 2.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
  1. Defaults !requiretty
  2. %qubes ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t NOPASSWD: ALL
  3. # WTF?! Have you lost your mind?!
  4. #
  5. # In Qubes VMs there is no point in isolating the root account from
  6. # the user account. This is because all the user data are already
  7. # accessible from the user account, so there is no direct benefit for
  8. # the attacker if she could escalate to root (there is even no benefit
  9. # in trying to install some persistent rootkits, as the VM's root
  10. # filesystem modifications are lost upon each start of a VM).
  11. #
  12. # One might argue that some hypothetical attacks against the
  13. # hypervisor or the few daemons/backends in Dom0 (so VM escape
  14. # attacks) most likely would require root access in the VM to trigger
  15. # the attack.
  16. #
  17. # That's true, but mere existence of such a bug in the hypervisor or
  18. # Dom0 that could be exploited by a malicious VM, no matter whether
  19. # requiring user, root, or even kernel access in the VM, would be
  20. # FATAL. In such situation (if there was such a bug in Xen) there
  21. # really is no comforting that: "oh, but the mitigating factor was
  22. # that the attacker needed root in VM!" We're not M$, and we're not
  23. # gonna BS our users that there are mitigating factors in that case,
  24. # and for sure, root/user isolation is not a mitigating factor.
  25. #
  26. # Because, really, if somebody could find and exploit a bug in the Xen
  27. # hypervisor -- as of 2016, there have been only three publicly disclosed
  28. # exploitable bugs in the Xen hypervisor from a VM -- then it would be
  29. # highly unlikely that that person couldn't also find a user-to-root
  30. # escalation in the VM (which as we know from history of UNIX/Linux
  31. # happens all the time).
  32. #
  33. # At the same time allowing for easy user-to-root escalation in a VM
  34. # is simply convenient for users, especially for update installation.
  35. #
  36. # Currently this still doesn't work as expected, because some idotic
  37. # piece of software called PolKit uses own set of policies. We're
  38. # planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
  39. # simple experiment: start 'xinput test' in one xterm, running as
  40. # user, then open some app that uses PolKit and asks for root
  41. # password, e.g. gpk-update-viewer -- observe how all the keystrokes
  42. # with root password you enter into the "secure" PolKit dialog box can
  43. # be seen by the xinput program...)
  44. #
  45. # joanna.
  46. # vim: ft=sudoers