mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Merge remote-tracking branch 'origin/main' into pr-1357
This commit is contained in:
Andrew David Wong
commit
b42ad4c01c
@ -4,8 +4,6 @@ title: Qubes OS 4.2.0 release notes
|
||||
permalink: /doc/releases/4.2/release-notes/
|
||||
---
|
||||
|
||||
_**Please note:** This page is still an unfinished draft in progress. It is being updated as Qubes 4.2 development and testing continues._
|
||||
|
||||
## New features and improvements since Qubes 4.1
|
||||
|
||||
- Dom0 upgraded to Fedora 37 ([#6982](https://github.com/QubesOS/qubes-issues/issues/6982))
|
||||
@ -13,7 +11,7 @@ _**Please note:** This page is still an unfinished draft in progress. It is bein
|
||||
- Default Debian template upgraded to Debian 12
|
||||
- Default Fedora and Debian templates use Xfce instead of GNOME ([#7784](https://github.com/QubesOS/qubes-issues/issues/7784))
|
||||
- SELinux support in Fedora templates ([#4239](https://github.com/QubesOS/qubes-issues/issues/4239))
|
||||
- Several GUI applications rewritten, including:
|
||||
- Several GUI applications rewritten (screenshots below), including:
|
||||
- Applications Menu (also available as preview in R4.1) ([#6665](https://github.com/QubesOS/qubes-issues/issues/6665)), ([#5677](https://github.com/QubesOS/qubes-issues/issues/5677))
|
||||
- Qubes Global Settings ([#6898](https://github.com/QubesOS/qubes-issues/issues/6898))
|
||||
- Create New Qube
|
||||
@ -25,9 +23,22 @@ _**Please note:** This page is still an unfinished draft in progress. It is bein
|
||||
- Official packages built using Qubes Builder v2 ([#6486](https://github.com/QubesOS/qubes-issues/issues/6486))
|
||||
- Split GPG management in Qubes Global Settings
|
||||
- Qrexec services use new qrexec policy format by default (but old format is still supported) ([#8000](https://github.com/QubesOS/qubes-issues/issues/8000))
|
||||
- Improved keyboard layout switching
|
||||
|
||||
For a full list, including more detailed descriptions, please see
|
||||
[here](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.2%22+label%3A%22release+notes%22+is%3Aclosed).
|
||||
For a full list, including more detailed descriptions, please see [here](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+sort%3Aupdated-desc+milestone%3A%22Release+4.2%22+label%3A%22release+notes%22+is%3Aclosed). Below are some screenshots of the new and improved Qubes GUI tools.
|
||||
|
||||
The new Qubes OS Update tool:
|
||||
|
||||
[](/attachment/site/4-2_update.png)
|
||||
|
||||
The new Qubes OS Global Config tool:
|
||||
|
||||
[](/attachment/site/4-2_global-config_1.png)
|
||||
[](/attachment/site/4-2_global-config_2.png)
|
||||
|
||||
The new Qubes OS Policy Editor tool:
|
||||
|
||||
[](/attachment/site/4-2_policy-editor.png)
|
||||
|
||||
## Known issues
|
||||
|
||||
|
||||
@ -86,25 +86,27 @@ Additionally, disposable VMs are tightly integrated -- RPC to a DisposableVM is
|
||||
|
||||
### Policy files
|
||||
|
||||
The dom0 directory `/etc/qubes-rpc/policy/` contains a file for each available RPC action that a VM might call.
|
||||
Together the contents of these files make up the RPC access policy database.
|
||||
The dom0 directory `/etc/qubes/policy.d/` contains files that set policy for each available RPC action that a VM might call.
|
||||
For example, `/etc/qubes/policy.d/90-default.policy` contains the default policy settings.
|
||||
When making changes to existing policies it is recommended that you create a *new* policy file starting with a lower number, like `/etc/qubes/policy.d/30-user.policy`.
|
||||
You may keep your custom policies in one file like `/etc/qubes/policy.d/30-user.policy`, or you may choose to have multiple files, like `/etc/qubes/policy.d/10-copy.policy`, `/etc/qubes/policy.d/10-open.policy`.
|
||||
Together the contents of these files make up the RPC access policy database: the files are merged, with policies in lower number files overriding policies in higher numbered files.
|
||||
|
||||
Policies are defined in lines with the following format:
|
||||
|
||||
```
|
||||
srcvm destvm (allow|deny|ask[,default_target=default_target_VM])[,user=user_to_run_as][,target=VM_to_redirect_to]
|
||||
service-name|* +argument|* source destination action [options]
|
||||
```
|
||||
|
||||
You can specify srcvm and destvm by name or by one of the reserved keywords such as `@anyvm`, `@dispvm`, or `dom0`.
|
||||
(Of these three, only `@anyvm` keyword makes sense in the srcvm field.
|
||||
You can specify the source and destination by name or by one of the reserved keywords such as `*`, `@dispvm`, or `dom0`.
|
||||
(Of these three, only `*` keyword makes sense in the source field.
|
||||
Service calls from dom0 are currently always allowed, and `@dispvm` means "new VM created for this particular request," so it is never a source of request.)
|
||||
Other methods using *tags* and *types* are also available (and discussed below).
|
||||
|
||||
Whenever a RPC request for an action is received, the domain checks the first matching line of the relevant file in `/etc/qubes-rpc/policy/` to determine access:
|
||||
Whenever a RPC request for an action is received, the domain checks the first matching line of the files in `/etc/qubes/policy.d/` to determine access:
|
||||
whether to allow the request, what VM to redirect the execution to, and what user account the program should run under.
|
||||
Note that if the request is redirected (`target=` parameter), policy action remains the same -- even if there is another rule which would otherwise deny such request.
|
||||
If no policy rule is matched, the action is denied.
|
||||
If the policy file does not exist, the user is prompted to create one.
|
||||
If there is still no policy file after prompting, the action is denied.
|
||||
|
||||
In the target VM, a file in either of the following locations must exist, containing the file name of the program that will be invoked, or being that program itself -- in which case it must have executable permission set (`chmod +x`):
|
||||
- `/etc/qubes-rpc/RPC_ACTION_NAME` when you make it in the template qube;
|
||||
@ -145,14 +147,14 @@ For DisposableVMs, `@dispvm:DISP_VM` is very similar to `@dispvm` but forces usi
|
||||
For example:
|
||||
|
||||
```
|
||||
anon-whonix @dispvm:anon-whonix-dvm allow
|
||||
* * anon-whonix @dispvm:anon-whonix-dvm allow
|
||||
```
|
||||
|
||||
Adding such policy itself will not force usage of this particular `DISP_VM` - it will only allow it when specified by the caller.
|
||||
But `@dispvm:DISP_VM` can also be used as target in request redirection, so _it is possible_ to force particular `DISP_VM` usage, when caller didn't specify it:
|
||||
|
||||
```
|
||||
anon-whonix @dispvm allow,target=@dispvm:anon-whonix-dvm
|
||||
* * anon-whonix @dispvm allow target=@dispvm:anon-whonix-dvm
|
||||
```
|
||||
|
||||
Note that without redirection, this rule would allow using default Disposable VM (`default_dispvm` VM property, which itself defaults to global `default_dispvm` property).
|
||||
@ -166,15 +168,15 @@ By default no VM is selected, even if the caller provided some, but policy can s
|
||||
For example:
|
||||
|
||||
```
|
||||
work-mail work-archive allow
|
||||
work-mail @tag:work ask,default_target=work-files
|
||||
work-mail @default ask,default_target=work-files
|
||||
* * 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 first rule allows calls 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.
|
||||
The third rule allows 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.
|
||||
|
||||
### RPC services and security
|
||||
|
||||
@ -213,9 +215,16 @@ With arguments, it is easier to write more precise policies using the "allow" an
|
||||
(Writing too many "ask" policies offloads additional decisions to the user.
|
||||
Generally, the fewer choices the user must make, the lower the chance to make a mistake.)
|
||||
|
||||
Each specific argument that we want to use needs its own policy in dom0 at a path like `/etc/qubes-rpc/policy/RPC_ACTION_NAME+ARGUMENT`.
|
||||
So for instance, we might have policies called `test.Device`, `test.Device+device1` and `test.Device+device2`.
|
||||
If the policy for the specific argument is not set (that is, if no file exists for `RPC_ACTION_NAME+ARGUMENT`), then dom0 uses the default policy with no argument for this service.
|
||||
The argument is specified in the second column of the policy line, as +ARGUMENT.
|
||||
If the policy uses "\*" as an argument, then it will match any argument (including no argument).
|
||||
As rules are processed in order, any lines with a specific argument below the line with the wildcard argument will be ignored.
|
||||
So for instance, we might have policies which are different depending on the argument:
|
||||
|
||||
```
|
||||
Device +device1 * * allow
|
||||
Device +device2 * * deny
|
||||
Device * * * ask
|
||||
```
|
||||
|
||||
When calling a service that takes an argument, just add the argument to the service name separated with `+`.
|
||||
|
||||
@ -265,10 +274,10 @@ ln -s /usr/bin/our_test_add_server /etc/qubes-rpc/test.Add
|
||||
```
|
||||
|
||||
The administrative domain will direct traffic based on the current RPC policies.
|
||||
In dom0, create a file at `/etc/qubes-rpc/policy/test.Add` containing the following:
|
||||
In dom0, create a file at `/etc/qubes/policy.d/30-test.policy` containing the following:
|
||||
|
||||
```
|
||||
@anyvm @anyvm ask
|
||||
test.Add * * * ask
|
||||
```
|
||||
|
||||
This will allow our client and server to communicate.
|
||||
@ -312,17 +321,15 @@ Make sure the file is executable!
|
||||
(The service argument is already sanitized by qrexec framework.
|
||||
It is guaranteed to not contain any spaces or slashes, so there should be no need for additional path sanitization.)
|
||||
|
||||
Now we create three policy files in dom0.
|
||||
See the table below for details.
|
||||
Now we create the policy file in dom0, at `/etc/qubes/policy.d/30-test.policy`.
|
||||
The contents of the file are below.
|
||||
Replace "source_vm1" and others with the names of your own chosen domains.
|
||||
|
||||
|------------------------------------------------------------------------|
|
||||
| Path to file in dom0 | Policy contents |
|
||||
|-------------------------------------------+----------------------------|
|
||||
| /etc/qubes-rpc/policy/test.File | @anyvm @anyvm deny |
|
||||
| /etc/qubes-rpc/policy/test.File+testfile1 | source_vm1 target_vm allow |
|
||||
| /etc/qubes-rpc/policy/test.File+testfile2 | source_vm2 target_vm allow |
|
||||
|------------------------------------------------------------------------|
|
||||
```
|
||||
test.File +testfile1 source_vm1 target_vm allow
|
||||
test.File +testfile2 source_vm2 target_vm allow
|
||||
test.File * * * deny
|
||||
```
|
||||
|
||||
With this done, we can run some tests.
|
||||
Invoke RPC from `source_vm1` via
|
||||
@ -332,11 +339,12 @@ Invoke RPC from `source_vm1` via
|
||||
```
|
||||
|
||||
We should get the contents of `/home/user/testfile1` printed to the terminal.
|
||||
Invoking the service from `source_vm2` should work the same, and `testfile2` should also work.
|
||||
Invoking the service from `source_vm2` should result in a denial, but `testfile2` should work.
|
||||
|
||||
```
|
||||
[user@source_vm2] $ qrexec-client-vm target_vm test.File+testfile1
|
||||
Request refused
|
||||
[user@source_vm2] $ qrexec-client-vm target_vm test.File+testfile2
|
||||
```
|
||||
|
||||
But when invoked with other arguments or from a different VM, it should be denied.
|
||||
And when invoked with other arguments or from a different VM, it should also be denied.
|
||||
|
||||
@ -57,7 +57,7 @@ Labels and projects are features of GitHub's issue tracking system that we use t
|
||||
|
||||
### Labels
|
||||
|
||||
When an issue is first created, certain [labels](https://github.com/QubesOS/qubes-issues/labels) may automatically be applied to it based on the type of issue the reporter selected. For example, if someone selects the "Bug report" template, then the `T: bug` label will automatically be applied to that issue. After that, only Qubes team members have permission to modify labels. Many labels have descriptions on them that can be viewed by hovering over them or on the [list of labels](https://github.com/QubesOS/qubes-issues/labels. Let's go over some of the most important ones.
|
||||
When an issue is first created, certain [labels](https://github.com/QubesOS/qubes-issues/labels) may automatically be applied to it based on the type of issue the reporter selected. For example, if someone selects the "Bug report" template, then the `T: bug` label will automatically be applied to that issue. After that, only Qubes team members have permission to modify labels. Many labels have descriptions on them that can be viewed by hovering over them or on the [list of labels](https://github.com/QubesOS/qubes-issues/labels). Let's go over some of the most important ones.
|
||||
|
||||
#### Type
|
||||
|
||||
|
||||
@ -27,7 +27,7 @@ in-place:
|
||||
current installation.
|
||||
2. [Download](/downloads/) the latest 4.2 release.
|
||||
3. Follow the [installation guide](/doc/installation-guide/) to install Qubes
|
||||
4.1.
|
||||
4.2.
|
||||
4. [Restore from your
|
||||
backup](/doc/how-to-back-up-restore-and-migrate/#restoring-from-a-backup) on
|
||||
your new 4.2 installation.
|
||||
@ -48,8 +48,8 @@ can install it with the following command in the dom0 terminal:
|
||||
|
||||
sudo qubes-dom0-update -y qubes-dist-upgrade
|
||||
|
||||
The upgrade consists of five stages --- three before restarting the system ---
|
||||
labeled "STAGE 1" through "STAGE 3" in the options list below, and two after restarting the system --- labeled as "STAGE 4" and "STAGE 5" below.
|
||||
The upgrade consists of six stages --- three before restarting the system ---
|
||||
labeled "STAGE 1" through "STAGE 3" in the options list below, and three after restarting the system --- labeled as "STAGE 4" through "STAGE 6" below.
|
||||
|
||||
Full list of options can be obtained with `qubes-dist-upgrade --help`:
|
||||
|
||||
@ -59,14 +59,16 @@ Full list of options can be obtained with `qubes-dist-upgrade --help`:
|
||||
|
||||
Options:
|
||||
--update, -t (STAGE 1) Update of dom0, TemplatesVM and StandaloneVM.
|
||||
--release-upgrade, -r (STAGE 2) Update 'qubes-release' for Qubes R4.1.
|
||||
--dist-upgrade, -s (STAGE 3) Upgrade to Qubes R4.1 and Fedora 32 repositories.
|
||||
--template-standalone-upgrade, -l (STAGE 4) Upgrade templates and standalone VMs to R4.1 repository.
|
||||
--release-upgrade, -r (STAGE 2) Update 'qubes-release' for Qubes R4.2.
|
||||
--dist-upgrade, -s (STAGE 3) Upgrade to Qubes R4.2 and Fedora 37 repositories.
|
||||
--template-standalone-upgrade, -l (STAGE 4) Upgrade templates and standalone VMs to R4.2 repository.
|
||||
--finalize, -x (STAGE 5) Finalize upgrade. It does:
|
||||
- resync applications and features
|
||||
- cleanup salt states
|
||||
--all-pre-reboot Execute stages 1 do 3
|
||||
--all-post-reboot Execute stages 4 and 5
|
||||
--convert-policy, -p (STAGE 6) Convert qrexec policy in /etc/qubes-rpc/policy
|
||||
to the new format in /etc/qubes/policy.d.
|
||||
--all-pre-reboot Execute stages 1 to 3
|
||||
--all-post-reboot Execute stages 4 to 6
|
||||
|
||||
--assumeyes, -y Automatically answer yes for all questions.
|
||||
--usbvm, -u Current UsbVM defined (default 'sys-usb').
|
||||
|
||||
@ -51,9 +51,9 @@ The [Dasharo FidelisGuard Z690](https://3mdeb.com/shop/open-source-hardware/dash
|
||||
|
||||
### NovaCustom NV41 Series
|
||||
|
||||
[](https://configurelaptop.eu/nv41-series/)
|
||||
[](https://novacustom.com/product/nv41-series/)
|
||||
|
||||
The [NovaCustom NV41 Series](https://configurelaptop.eu/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/05/03/novacustom-nv41-series-qubes-certified/) for details.
|
||||
The [NovaCustom NV41 Series](https://novacustom.com/product/nv41-series/) is a 14-inch custom laptop. It is certified for Qubes OS 4.X. Read our [announcement](/news/2023/05/03/novacustom-nv41-series-qubes-certified/) for details.
|
||||
|
||||
### NitroPC Pro
|
||||
|
||||
|
||||
@ -26,6 +26,20 @@ Qubes Windows Tools (QWT) are a set of programs and drivers that provide integra
|
||||
- **Audio** - Audio support is available even without QWT installation if `qvm-features audio-model` is set as `ich6`
|
||||
|
||||
|
||||
**Note:** Due to the security problems described in [QSB-091](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-091-2023.txt), installation of Qubes Windows Tools is currently blocked. Instead, a text file containing a warning is displayed. Currently, it is difficult to estimate the severity of the risks posed by the sources of the Xen drivers used in QWT possibly being compromised, so it was decided not to offer direct QWT installation until this problem could be treated properly. While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself. If you **understand** this risk and are **willing to take it**, you can still install the previous versions of Qubes Windows Tools, using the command
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.68
|
||||
|
||||
for Qubes R4.1.2, or
|
||||
|
||||
sudo qubes-dom0-update qubes-windows-tools-4.1.69
|
||||
|
||||
for Qubes R4.2.0, respectively, instead of the command listed in step 1 of the installation described below. This will provide the .iso file to be presented as installation drive to the Windows qube in step 3 of the QWT installation.
|
||||
|
||||
If you prefer to download the corresponding .rpm files for manual QWT installation, these are still available from the repositories (version [4.1.68-1](https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.68-1.noarch.rpm) for Qubes R4.1.2 and version [4.1.69-1](https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.noarch.rpm) for Qubes R4.2.0).
|
||||
|
||||
**Warning**: These older versions of Qubes Windows Tools will be replaced during the next dom0 update by the current dummy version 4.1.70-1. This can be inhibited by appending the line `exclude=qubes-windows-tools` to the file `/etc/dnf/dnf.conf` in dom0. But this will also stop any further QWT updates - so be sure to remove this line when - hopefully - a new functional version 4.1.71-1 of Qubes Windows Tools will be made available!!!
|
||||
|
||||
**Note**: If you choose to move profiles, drive letter `Q:` must be assigned to the secondary (private) disk.
|
||||
|
||||
**Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user