Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-10-01 01:25:40 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'pierwill-update-qrexec-keywords'

Browse Source
This commit is contained in:
Andrew David Wong 2019-08-23 06:54:19 -05:00
commit da4f21a703
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
5 changed files with 17 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
user/advanced-configuration/rpc-policy.md
View File

@ -15,10 +15,10 @@ Here's an example of an RPC policy file in dom0:
```
[user@dom0 user ~]$ cat /etc/qubes-rpc/policy/qubes.FileCopy
(...)
$tag:work $tag:work allow
$tag:work $anyvm deny
$anyvm $tag:work deny
$anyvm $anyvm ask
@tag:work @tag:work allow
@tag:work @anyvm deny
@anyvm @tag:work deny
@anyvm @anyvm ask
```
It has three columns (from left to right): source, destination, and permission.
@ -32,7 +32,7 @@ Now, the whole policy file is parsed from top to bottom.
As soon as a rule is found that matches the action being evaluated, parsing stops.
We can see what this means by looking at the second row.
It says that we're **denied** from attempting to copy a file **from** any VM tagged with "work" **to** any VM whatsoever.
(That's what the `$anyvm` keyword means -- literally any VM in the system).
(That's what the `@anyvm` keyword means -- literally any VM in the system).
But, wait a minute, didn't we just say (in the first row) that all the VMs tagged with work are **allowed** to copy files to each other?
That's exactly right.
The first and second rows contradict each other, but that's intentional.
@ -46,7 +46,7 @@ Rather, it means that only VMs that match an earlier rule can do so (in this cas
The fourth and final row says that we're **asked** (i.e., prompted) to copy files **from** any VM in the system **to** any VM in the system.
(This rule was already in the policy file by default.
We added the first three.)
Note that it wouldn't make sense to add any rules after this one, since every possible pair of VMs will match the `$anyvm $anyvm` pattern.
Note that it wouldn't make sense to add any rules after this one, since every possible pair of VMs will match the `@anyvm @anyvm` pattern.
Therefore, parsing will always stop at this rule, and no rules below it will ever be evaluated.
All together, the three rules we added say that all VMs tagged with "work" are allowed to copy files to each other; however, they're denied from copying files to other VMs (without the "work" tag), and other VMs (without the "work" tag) are denied from copying files to them.
@ -54,5 +54,8 @@ The fourth rule means that the user gets prompted for any situation not already
Further details about how this system works can be found in [Qrexec: command execution in VMs][qrexec3].
(***Note**: the `$` character is deprecated in qrexec keywords -- please use `@` instead (e.g. `@anyvm`).
For more information, see the bulletin [here](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt).*)
[qrexec3]: /doc/qrexec3/

4
user/common-tasks/copy-paste.md
View File

@ -62,8 +62,8 @@ You may wish to configure this policy in order to prevent user error.
For example, if you are certain that you never wish to paste *into* your "vault" AppVM (and it is highly recommended that you do not), then you should edit the policy as follows:
~~~
$anyvm vault deny
$anyvm $anyvm ask
@anyvm vault deny
@anyvm @anyvm ask
~~~
Shortcut Configuration

2
user/common-tasks/disposablevm.md
View File

@ -123,7 +123,7 @@ Sometimes it can be useful to start an arbitrary program in a DisposableVM.
This can be done from an AppVM by running
~~~
[user@vault ~]$ qvm-run '$dispvm' xterm
[user@vault ~]$ qvm-run '@dispvm' xterm
~~~
The created DisposableVM can be accessed via other tools (such as `qvm-copy-to-vm`) using its `disp####` name as shown in the Qubes Manager or `qvm-ls`.

8
user/common-tasks/software-update-vm.md
View File

@ -218,12 +218,12 @@ This new design allows for templates to be updated even when they are not connec
Example policy file in R4.0 (with whonix installed, but not set as default updatevm for all templates):
```
# any VM with tag `whonix-updatevm` should use `sys-whonix`; this tag is added to `whonix-gw` and `whonix-ws` during installation and is preserved during template clone
$tag:whonix-updatevm $default allow,target=sys-whonix
$tag:whonix-updatevm $anyvm deny
@tag:whonix-updatevm @default allow,target=sys-whonix
@tag:whonix-updatevm @anyvm deny
# other templates use sys-net
$type:TemplateVM $default allow,target=sys-net
$anyvm $anyvm deny
@type:TemplateVM @default allow,target=sys-net
@anyvm @anyvm deny
```
Note on treating AppVM's root filesystem non-persistence as a security feature

2
user/security-in-qubes/vm-sudo.md
View File

@ -105,7 +105,7 @@ Do not rely on this for extra security.**
1. Adding Dom0 "VMAuth" service:
[root@dom0 /]# echo "/usr/bin/echo 1" >/etc/qubes-rpc/qubes.VMAuth
[root@dom0 /]# echo "\$anyvm dom0 ask,default_target=dom0" \
[root@dom0 /]# echo "\@anyvm dom0 ask,default_target=dom0" \
>/etc/qubes-rpc/policy/qubes.VMAuth
(Note: any VMs you would like still to have passwordless root access (e.g. TemplateVMs) can be specified in the second file with "\<vmname\> dom0 allow")