0fac1aa45c
By settinf Defaults role/type parameters, sudo starts asking for
password when called as root. It isn't clear why this happens, but
rollback that change. Instead, set ROLE/TYPE just for the rule for the
'qubes' group, which already has NOPASSWD option.
Fixes 3bcc1c3 "“sudo” must remove SELinux restrictions"
49 lines
2.3 KiB
Plaintext
49 lines
2.3 KiB
Plaintext
Defaults !requiretty
|
|
%qubes ALL=(ALL) ROLE=unconfined_r TYPE=unconfined_t 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 -- as of 2016, there have been only three publicly disclosed
|
|
# exploitable bugs in the Xen hypervisor from a VM -- then it would be
|
|
# highly unlikely that that person couldn't also find a user-to-root
|
|
# escalation in the 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.
|
|
|
|
# vim: ft=sudoers
|