|
@@ -4,4 +4,26 @@
|
|
## Please use a single # to start your custom comments
|
|
## Please use a single # to start your custom comments
|
|
|
|
|
|
$anyvm $dispvm allow
|
|
$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
|
|
|
|
+#
|
|
|
|
+#
|