VMSudo: fix git link and formatting
This commit is contained in:
Marek Marczykowski-Górecki
parent
e5168b0da2
commit
21fd43f648
112
VMSudo.md
112
VMSudo.md
|
|
@ -8,86 +8,78 @@ redirect_from: /wiki/VMSudo/
|
||||||
Password-less root access in VM
|
Password-less root access in VM
|
||||||
===============================
|
===============================
|
||||||
|
|
||||||
Background ([/etc/sudoers.d/qubes](http://git.qubes-os.org/?p=qubes-r2/core-agent-linux.git;a=blob;f=misc/qubes.sudoers;hb=HEAD) in VM):
|
Background ([/etc/sudoers.d/qubes](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/misc/qubes.sudoers) in VM):
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
user ALL=(ALL) NOPASSWD: ALL
|
||||||
user ALL=(ALL) NOPASSWD: ALL
|
|
||||||
|
|
||||||
# WTF?! Have you lost your mind?!
|
# WTF?! Have you lost your mind?!
|
||||||
#
|
#
|
||||||
# In Qubes VMs there is no point in isolating the root account from
|
# 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
|
# the user account. This is because all the user data are already
|
||||||
# accessible from the user account, so there is no direct benefit for
|
# 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
|
# 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
|
# in trying to install some persistent rootkits, as the VM's root
|
||||||
# filesystem modifications are lost upon each start of a VM).
|
# filesystem modifications are lost upon each start of a VM).
|
||||||
#
|
#
|
||||||
# One might argue that some hypothetical attacks against the
|
# One might argue that some hypothetical attacks against the
|
||||||
# hypervisor or the few daemons/backends in Dom0 (so VM escape
|
# hypervisor or the few daemons/backends in Dom0 (so VM escape
|
||||||
# attacks) most likely would require root access in the VM to trigger
|
# attacks) most likely would require root access in the VM to trigger
|
||||||
# the attack.
|
# the attack.
|
||||||
#
|
#
|
||||||
# That's true, but mere existence of such a bug in the hypervisor or
|
# 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
|
# Dom0 that could be exploited by a malicious VM, no matter whether
|
||||||
# requiring user, root, or even kernel access in the VM, would be
|
# 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
|
# FATAL. In such situation (if there was such a bug in Xen) there
|
||||||
# really is no comforting that: "oh, but the mitigating factor was
|
# 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
|
# 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,
|
# gonna BS our users that there are mitigating factors in that case,
|
||||||
# and for sure, root/user isolation is not a mitigating factor.
|
# and for sure, root/user isolation is not a mitigating factor.
|
||||||
#
|
#
|
||||||
# Because, really, if somebody could find and exploit a bug in the Xen
|
# Because, really, if somebody could find and exploit a bug in the Xen
|
||||||
# hypervisor -- so far there have been only one (!) publicly disclosed
|
# hypervisor -- so far there have been only one (!) publicly disclosed
|
||||||
# exploitable bug in the Xen hypervisor from a VM, found in 2008,
|
# exploitable bug in the Xen hypervisor from a VM, found in 2008,
|
||||||
# incidentally by one of the Qubes developers (RW) -- then it would be
|
# 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
|
# 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
|
# escalation in VM (which as we know from history of UNIX/Linux
|
||||||
# happens all the time).
|
# happens all the time).
|
||||||
#
|
#
|
||||||
# At the same time allowing for easy user-to-root escalation in a VM
|
# At the same time allowing for easy user-to-root escalation in a VM
|
||||||
# is simply convenient for users, especially for update installation.
|
# is simply convenient for users, especially for update installation.
|
||||||
#
|
#
|
||||||
# Currently this still doesn't work as expected, because some idotic
|
# Currently this still doesn't work as expected, because some idotic
|
||||||
# piece of software called PolKit uses own set of policies. We're
|
# 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
|
# planning to address this in Beta 2. (Why PolKit is an idiocy? Do a
|
||||||
# simple experiment: start 'xinput test' in one xterm, running as
|
# simple experiment: start 'xinput test' in one xterm, running as
|
||||||
# user, then open some app that uses PolKit and asks for root
|
# user, then open some app that uses PolKit and asks for root
|
||||||
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
|
# password, e.g. gpk-update-viewer -- observe how all the keystrokes
|
||||||
# with root password you enter into the "secure" PolKit dialog box can
|
# with root password you enter into the "secure" PolKit dialog box can
|
||||||
# be seen by the xinput program...)
|
# be seen by the xinput program...)
|
||||||
#
|
#
|
||||||
# joanna.
|
# joanna.
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
Below is a complete list of configuration made according to the above statement, with (not necessary complete) list of mechanisms depending on each of them:
|
Below is a complete list of configuration made according to the above statement, with (not necessary complete) list of mechanisms depending on each of them:
|
||||||
|
|
||||||
1. sudo (/etc/sudoers.d/qubes):
|
1. sudo (/etc/sudoers.d/qubes):
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
user ALL=(ALL) NOPASSWD: ALL
|
user ALL=(ALL) NOPASSWD: ALL
|
||||||
(...)
|
(...)
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
- easy user-\>root access (main option for the user)
|
- easy user->root access (main option for the user)
|
||||||
- qvm-usb (not really working, as of R2)
|
- qvm-usb (not really working, as of R2)
|
||||||
|
|
||||||
2. PolicyKit (/etc/polkit-1/rules.d/00-qubes-allow-all.rules):
|
2. PolicyKit (/etc/polkit-1/rules.d/00-qubes-allow-all.rules):
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
//allow any action, detailed reasoning in sudoers.d/qubes
|
//allow any action, detailed reasoning in sudoers.d/qubes
|
||||||
polkit.addRule(function(action,subject) { return polkit.Result.YES; });
|
polkit.addRule(function(action,subject) { return polkit.Result.YES; });
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
and /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla:
|
and /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla:
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
[Qubes allow all]
|
[Qubes allow all]
|
||||||
Identity=*
|
Identity=*
|
||||||
Action=*
|
Action=*
|
||||||
ResultAny=yes
|
ResultAny=yes
|
||||||
ResultInactive=yes
|
ResultInactive=yes
|
||||||
ResultActive=yes
|
ResultActive=yes
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
- NetworkManager configuration from normal user (nm-applet)
|
- NetworkManager configuration from normal user (nm-applet)
|
||||||
- updates installation (gpk-update-viewer)
|
- updates installation (gpk-update-viewer)
|
||||||
|
|
@ -104,34 +96,26 @@ While ITL still supports the statement above, some Qubes users may want to enabl
|
||||||
|
|
||||||
1. Adding Dom0 "VMAuth" service:
|
1. Adding Dom0 "VMAuth" service:
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
[root@dom0 /]# echo -n "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
|
[root@dom0 /]# echo -n "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
|
||||||
[root@dom0 /]# echo -n "$anyvm dom0 ask" >/etc/qubes-rpc/policy/qubes.VMAuth
|
[root@dom0 /]# echo -n "$anyvm dom0 ask" >/etc/qubes-rpc/policy/qubes.VMAuth
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
(Note: any VMs you would like still to have password-less root access (e.g. TemplateVMs) can be specified in the second file with "\<vmname\> dom0 allow")
|
(Note: any VMs you would like still to have password-less root access (e.g. TemplateVMs) can be specified in the second file with "\<vmname\> dom0 allow")
|
||||||
|
|
||||||
2. Configuring TemplateVM to prompt Dom0 for any authorization request:
|
2. Configuring TemplateVM to prompt Dom0 for any authorization request:
|
||||||
- In /etc/pam.d/system-auth, replace all lines beginning with "auth" with one line:
|
- In /etc/pam.d/system-auth, replace all lines beginning with "auth" with one line:
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
auth [success=done default=die] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /usr/bin/grep -q ^1$
|
auth [success=done default=die] pam_exec.so seteuid /usr/lib/qubes/qrexec-client-vm dom0 qubes.VMAuth /usr/bin/grep -q ^1$
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
- Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:
|
- Require authentication for sudo. Replace the first line of /etc/sudoers.d/qubes with:
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
user ALL=(ALL) ALL
|
user ALL=(ALL) ALL
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
- Disable PolKit's default-allow behavior:
|
- Disable PolKit's default-allow behavior:
|
||||||
|
|
||||||
{% highlight trac-wiki %}
|
|
||||||
[root@fedora-20-x64]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
|
[root@fedora-20-x64]# rm /etc/polkit-1/rules.d/00-qubes-allow-all.rules
|
||||||
[root@fedora-20-x64]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
|
[root@fedora-20-x64]# rm /etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla
|
||||||
{% endhighlight %}
|
|
||||||
|
|
||||||
Dom0 password-less root access
|
Dom0 password-less root access
|
||||||
------------------------------
|
------------------------------
|
||||||
|
|
||||||
There is also password-less user-\>root access in dom0. As stated in comment in sudo configuration there (different one than VMs one), there is really no point in user/root isolation, because all the user data (and VM management interface) is already accessible from dom0 user level, so there is nothing more to get from dom0 root account.
|
There is also password-less user->root access in dom0. As stated in comment in sudo configuration there (different one than VMs one), there is really no point in user/root isolation, because all the user data (and VM management interface) is already accessible from dom0 user level, so there is nothing more to get from dom0 root account.
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue
Block a user