whonix: place "allow all" sudo configuration only build time
qubes-core-agent will provide appropriate file later so do not conflict with it.
This commit is contained in:
Marek Marczykowski-Górecki
parent
a91429751d
commit
43e319b562
1
scripts_debian/wheezy+whonix-gateway/09_cleanup_post.sh
Symbolic link
1
scripts_debian/wheezy+whonix-gateway/09_cleanup_post.sh
Symbolic link
@ -0,0 +1 @@
|
|||||||
|
../wheezy+whonix/09_cleanup_post.sh
|
||||||
@ -117,7 +117,7 @@ user::rwx
|
|||||||
group::r-x
|
group::r-x
|
||||||
other::---
|
other::---
|
||||||
|
|
||||||
# file: etc/sudoers.d/qubes
|
# file: etc/sudoers.d/whonix-build
|
||||||
# owner: root
|
# owner: root
|
||||||
# group: root
|
# group: root
|
||||||
user::r--
|
user::r--
|
||||||
|
|||||||
@ -1,46 +0,0 @@
|
|||||||
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.
|
|
||||||
@ -0,0 +1 @@
|
|||||||
|
user ALL=(ALL) NOPASSWD: ALL
|
||||||
1
scripts_debian/wheezy+whonix-workstation/09_cleanup_post.sh
Symbolic link
1
scripts_debian/wheezy+whonix-workstation/09_cleanup_post.sh
Symbolic link
@ -0,0 +1 @@
|
|||||||
|
../wheezy+whonix/09_cleanup_post.sh
|
||||||
@ -110,7 +110,7 @@ user::rwx
|
|||||||
group::r-x
|
group::r-x
|
||||||
other::---
|
other::---
|
||||||
|
|
||||||
# file: etc/sudoers.d/qubes
|
# file: etc/sudoers.d/whonix-build
|
||||||
# owner: root
|
# owner: root
|
||||||
# group: root
|
# group: root
|
||||||
user::r--
|
user::r--
|
||||||
|
|||||||
@ -1,46 +0,0 @@
|
|||||||
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.
|
|
||||||
@ -0,0 +1 @@
|
|||||||
|
user ALL=(ALL) NOPASSWD: ALL
|
||||||
18
scripts_debian/wheezy+whonix/09_cleanup_post.sh
Executable file
18
scripts_debian/wheezy+whonix/09_cleanup_post.sh
Executable file
@ -0,0 +1,18 @@
|
|||||||
|
#!/bin/sh
|
||||||
|
|
||||||
|
# ------------------------------------------------------------------------------
|
||||||
|
# Source external scripts
|
||||||
|
# ------------------------------------------------------------------------------
|
||||||
|
. ${SCRIPTSDIR}/vars.sh
|
||||||
|
. ./umount_kill.sh >/dev/null
|
||||||
|
|
||||||
|
# ------------------------------------------------------------------------------
|
||||||
|
# Configurations
|
||||||
|
# ------------------------------------------------------------------------------
|
||||||
|
if [ "${VERBOSE}" -ge 2 -o "${DEBUG}" == "1" ]; then
|
||||||
|
set -x
|
||||||
|
else
|
||||||
|
set -e
|
||||||
|
fi
|
||||||
|
|
||||||
|
rm -f "${INSTALLDIR}/etc/sudoers.d/whonix-build"
|
||||||
Loading…
Reference in New Issue
Block a user