Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-12-15 15:59:23 -05:00
Code Issues Projects Releases Packages Wiki Activity

Merge branch 'master' into spelling-grammar-fixes

Browse source 
Resolved conflicts in:
      basics_user/doc-guidelines.md
      basics_user/reporting-bugs.md
      common-tasks/backup-restore.md
      common-tasks/software-update-dom0.md
      common-tasks/software-update-vm.md
      common-tasks/usb.md
      configuration/disk-trim.md
      configuration/external-audio.md
      configuration/network-printer.md
      configuration/resize-disk-image.md
      configuration/resize-root-disk-image.md
      customization/fedora-minimal-template-customization.md
      managing-os/hvm.md
      managing-os/templates/archlinux.md
      privacy/whonix-install.md
      security/yubi-key.md
      troubleshooting/install-nvidia-driver.md
      troubleshooting/macbook-troubleshooting.md
This commit is contained in:
Marek Marczykowski-Górecki 2018-02-10 16:46:43 +01:00
commit 919f2ed17e
No known key found for this signature in database
GPG key ID: F32894BE9684938A
123 changed files with 2914 additions and 1254 deletions
Download patch file Download diff file Expand all files Collapse all files

2
services/dom0-secure-updates.md
View file

@ -14,7 +14,7 @@ Qubes Dom0 secure update procedure
Reasons for Dom0 updates
------------------------
Normally there should be few reasons for updating software in Dom0. This is because there is no networking in Dom0, which means that even if some bugs will be discovered e.g. in the Dom0 Desktop Manager, this really is not a problem for Qubes, because all the 3rd party software running in Dom0 is not accessible from VMs or network in any way. Some exceptions to the above include: Qubes GUI daemon, Xen store daemon, and disk back-ends (we plan to move the disk backends to untrusted domain in Qubes 2.0). Of course we believe this software is reasonably secure and we hope it will not need patching.
Normally there should be few reasons for updating software in Dom0. This is because there is no networking in Dom0, which means that even if some bugs will be discovered e.g. in the Dom0 Desktop Manager, this really is not a problem for Qubes, because all the third-party software running in Dom0 is not accessible from VMs or network in any way. Some exceptions to the above include: Qubes GUI daemon, Xen store daemon, and disk back-ends (we plan to move the disk backends to untrusted domain in Qubes 2.0). Of course we believe this software is reasonably secure and we hope it will not need patching.
However, we anticipate some other situations when updating Dom0 software might be required:

20
services/qrexec3.md
View file

@ -201,6 +201,26 @@ Target VM can be also specified as `$default`, which matches the case when
calling VM didn't specified any particular target (either by using `$default`
target, or empty target).
In Qubes 4.0 policy confirmation dialog (`ask` action) allow the user to
specify target VM. User can choose from VMs that, according to policy, would
lead to `ask` or `allow` actions. It is not possible to select VM that policy
would deny. By default no VM is selected, even if the caller provided some, but
policy can specify default value using `default_target=` parameter. For
example:
work-mail work-archive allow
work-mail $tag:work ask,default_target=work-files
work-mail $default ask,default_target=work-files
The first rule allow call from `work-mail` to `work-archive`, without any
confirmation.
The second rule will ask the user about calls from `work-mail` VM to any VM with
tag `work`. And the confirmation dialog will have `work-files` VM chosen by
default, regardless of the VM specified by the caller (`work-mail` VM). The
third rule allow the caller to not specify target VM at all and let the user
choose, still - from VMs with tag `work` (and `work-archive`, regardless of
tag), and with `work-files` as default.
### Service argument in policy
Sometimes just service name isn't enough to make reasonable qrexec policy. One