diff --git a/scripts_debian/wheezy+whonix-gateway/09_cleanup_post.sh b/scripts_debian/wheezy+whonix-gateway/09_cleanup_post.sh new file mode 120000 index 0000000..9728555 --- /dev/null +++ b/scripts_debian/wheezy+whonix-gateway/09_cleanup_post.sh @@ -0,0 +1 @@ +../wheezy+whonix/09_cleanup_post.sh \ No newline at end of file diff --git a/scripts_debian/wheezy+whonix-gateway/files/.facl b/scripts_debian/wheezy+whonix-gateway/files/.facl index 5065286..56e79de 100644 --- a/scripts_debian/wheezy+whonix-gateway/files/.facl +++ b/scripts_debian/wheezy+whonix-gateway/files/.facl @@ -117,7 +117,7 @@ user::rwx group::r-x other::--- -# file: etc/sudoers.d/qubes +# file: etc/sudoers.d/whonix-build # owner: root # group: root user::r-- diff --git a/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/qubes b/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/qubes deleted file mode 100644 index 8087a90..0000000 --- a/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/qubes +++ /dev/null @@ -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. diff --git a/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/whonix-build b/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/whonix-build new file mode 100644 index 0000000..5841129 --- /dev/null +++ b/scripts_debian/wheezy+whonix-gateway/files/etc/sudoers.d/whonix-build @@ -0,0 +1 @@ +user ALL=(ALL) NOPASSWD: ALL diff --git a/scripts_debian/wheezy+whonix-workstation/09_cleanup_post.sh b/scripts_debian/wheezy+whonix-workstation/09_cleanup_post.sh new file mode 120000 index 0000000..9728555 --- /dev/null +++ b/scripts_debian/wheezy+whonix-workstation/09_cleanup_post.sh @@ -0,0 +1 @@ +../wheezy+whonix/09_cleanup_post.sh \ No newline at end of file diff --git a/scripts_debian/wheezy+whonix-workstation/files/.facl b/scripts_debian/wheezy+whonix-workstation/files/.facl index 2e89eb9..9056544 100644 --- a/scripts_debian/wheezy+whonix-workstation/files/.facl +++ b/scripts_debian/wheezy+whonix-workstation/files/.facl @@ -110,7 +110,7 @@ user::rwx group::r-x other::--- -# file: etc/sudoers.d/qubes +# file: etc/sudoers.d/whonix-build # owner: root # group: root user::r-- diff --git a/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/qubes b/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/qubes deleted file mode 100644 index 8087a90..0000000 --- a/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/qubes +++ /dev/null @@ -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. diff --git a/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/whonix-build b/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/whonix-build new file mode 100644 index 0000000..5841129 --- /dev/null +++ b/scripts_debian/wheezy+whonix-workstation/files/etc/sudoers.d/whonix-build @@ -0,0 +1 @@ +user ALL=(ALL) NOPASSWD: ALL diff --git a/scripts_debian/wheezy+whonix/09_cleanup_post.sh b/scripts_debian/wheezy+whonix/09_cleanup_post.sh new file mode 100755 index 0000000..050cdc4 --- /dev/null +++ b/scripts_debian/wheezy+whonix/09_cleanup_post.sh @@ -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"