From e882ba15f71298a3ebd3346b8a5073afdda5c848 Mon Sep 17 00:00:00 2001 From: Joanna Rutkowska Date: Wed, 7 May 2014 13:50:37 +0200 Subject: [PATCH] qubes.VMShell.policy: use 'deny' rule by default when target is a regular AppVM --- qubes-rpc-policy/qubes.VMShell.policy | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/qubes-rpc-policy/qubes.VMShell.policy b/qubes-rpc-policy/qubes.VMShell.policy index 41217337..1038b76b 100644 --- a/qubes-rpc-policy/qubes.VMShell.policy +++ b/qubes-rpc-policy/qubes.VMShell.policy @@ -4,4 +4,26 @@ ## Please use a single # to start your custom comments $anyvm $dispvm allow -$anyvm $anyvm ask +$anyvm $anyvm deny + +# WARNING: The qubes.VMShell service is dangerous and there are really few +# cases when it could be safely used. Allowing one VM to execute qubes.VMShell +# over the other VM allows the former to TAKE FULL CONTROL over the later. In +# most cases this is not what we want! +# +# Instead we should be using task-specific qrexec services which provide +# assurance as to what program will be responding to the (untrusted) VM +# requests. +# +# It is, however, safe, in most cases, to allow ultimate control of the +# creating AppVM over the DisposableVM it creates as part of the qrexec service +# invocation. That's why by default we have "$anyvm $dispvm allow" rule. Note +# that it does _not_ allow any AppVM to execute qubes.VMShell service over any +# DispVM created in the system -- that would obviously be wrong. It only allows +# qubes.VMShell service access to the AppVM which creates the DispVM as part of +# this very service invocation. +# +# See e.g. this thread for some discussion: +# https://groups.google.com/d/msg/qubes-users/xnAByaL_bjI/3PjYdiTDW-0J +# +#