mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-08-06 05:34:27 -04:00
Merge branch 'main' into yubikey-nk-update
This commit is contained in:
UndeadDevel
GitHub
commit
d4e4388c5f
23 changed files with 715 additions and 254 deletions
|
|
@ -66,12 +66,16 @@ Normally Qubes doesn't let the user stop a NetVM if there are other qubes runnin
|
|||
But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in Dom0), Qubes R4.x will often automatically repair the connection.
|
||||
If it does not, then there is an easy way to restore the connection to the NetVM by issuing in dom0:
|
||||
|
||||
` qvm-prefs <vm> netvm <netvm> `
|
||||
```
|
||||
qvm-prefs <vm> netvm <netvm>
|
||||
```
|
||||
|
||||
Normally qubes do not connect directly to the actual NetVM (sys-net by default) which has networking devices, but rather to the default sys-firewall first, and in most cases it would be the NetVM that will crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers.
|
||||
In that case it is only necessary to issue the above command once, for the sys-firewall (this assumes default VM-naming used by the default Qubes installation):
|
||||
|
||||
` qvm-prefs sys-firewall netvm sys-net `
|
||||
```
|
||||
qvm-prefs sys-firewall netvm sys-net
|
||||
```
|
||||
|
||||
Network service qubes
|
||||
---------------------
|
||||
|
|
@ -304,12 +308,12 @@ nft add rule qubes custom-forward iif == "ens6" ip saddr 192.168.x.y/24 ip daddr
|
|||
|
||||
> Note: If you do not wish to limit the IP addresses connecting to the service, remove `ip saddr 192.168.x.y/24` from the rules
|
||||
|
||||
> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface.
|
||||
> If you want to expose the service on multiple interfaces, repeat the steps 2 and 3 described above, for each interface. Alternatively, you can leave out the interface completely.
|
||||
|
||||
Verify the rules on sys-net firewall correctly match the packets you want by looking at its counters, check for the counter lines in the chains `custom-forward` and `custom-dnat-qubeDEST`:
|
||||
|
||||
```
|
||||
nft list table ip qubes-firewall
|
||||
nft list table ip qubes
|
||||
```
|
||||
|
||||
In this example, we can see 7 packets in the forward rule, and 3 packets in the dnat rule:
|
||||
|
|
@ -331,7 +335,7 @@ chain custom-dnat-qubeDEST {
|
|||
telnet 192.168.x.n 443
|
||||
```
|
||||
|
||||
Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/rc.local` so they get set on sys-net start-up:
|
||||
Once you have confirmed that the counters increase, store the commands used in the previous steps in `/rw/config/qubes-firewall-user-script` so they get set on sys-net start-up:
|
||||
|
||||
```
|
||||
[user@sys-net user]$ sudo -i
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ ref: 165
|
|||
title: Passwordless root access in qubes
|
||||
---
|
||||
|
||||
Background (`/etc/sudoers.d/qubes` in VM):
|
||||
The background to passswordless root access is summarised in this statement, that used to be found at `/etc/sudoers.d/qubes` in each qube:
|
||||
|
||||
```
|
||||
user ALL=(ALL) NOPASSWD: ALL
|
||||
|
|
@ -59,59 +59,31 @@ user ALL=(ALL) NOPASSWD: ALL
|
|||
#
|
||||
# joanna.
|
||||
```
|
||||
The core of this statement continues to reflect the views of the Qubes developers.
|
||||
|
||||
Below is a complete list of configuration made according to the above statement, with (not necessary complete) list of mechanisms depending on each of them:
|
||||
Passwordless root is provided by the `qubes-core-agent-passwordless-root` package.
|
||||
Details of the implementation are [here](/doc/vm-sudo-implementation).
|
||||
|
||||
1. sudo (`/etc/sudoers.d/qubes`):
|
||||
[Minimal templates](/doc/templates/minimal/), which are intended for use by advanced users, do not have this package installed by default.
|
||||
|
||||
```
|
||||
user ALL=(ALL) NOPASSWD: ALL
|
||||
(...)
|
||||
```
|
||||
Replacing passwordless root access
|
||||
----------------------------------
|
||||
|
||||
- Easy user -> root access (main option for the user).
|
||||
- `qvm-usb` (not really working, as of R2).
|
||||
Some users may wish to modify their system by enabling user/root isolation in qubes.
|
||||
We do not support this in any packages, but users are free to remove the qubes-core-agent-passwordless-root package if they wish, using standard packaging tools.
|
||||
|
||||
2. PolicyKit (`/etc/polkit-1/rules.d/00-qubes-allow-all.rules`):
|
||||
|
||||
```
|
||||
//allow any action, detailed reasoning in sudoers.d/qubes
|
||||
polkit.addRule(function(action,subject) { return polkit.Result.YES; });
|
||||
```
|
||||
|
||||
and `/etc/polkit-1/localauthority/50-local.d/qubes-allow-all.pkla`:
|
||||
|
||||
```
|
||||
[Qubes allow all]
|
||||
Identity=*
|
||||
Action=*
|
||||
ResultAny=yes
|
||||
ResultInactive=yes
|
||||
ResultActive=yes
|
||||
```
|
||||
|
||||
- NetworkManager configuration from normal user (`nm-applet`).
|
||||
- Updates installation (`gpk-update-viewer`).
|
||||
- User can use pkexec just like sudo Note: above is needed mostly because Qubes user GUI session isn't treated by PolicyKit/logind as "local" session because of the way in which X server and session is started.
|
||||
Perhaps we will address this issue in the future, but this is really low priority.
|
||||
Patches welcomed anyway.
|
||||
|
||||
3. Empty root password:
|
||||
- Used for access to 'root' account from text console (`qvm-console-dispvm`) - the only way to access the VM when GUI isn't working.
|
||||
- Can be used for easy 'su -' from user to root.
|
||||
Root access can then be gained from dom0 by (e.g) `qvm-run -u root QUBE qubes-run-terminal`, or `qvm-console-dispvm QUBE`.
|
||||
|
||||
Replacing passwordless root access with Dom0 user prompt
|
||||
--------------------------------------------------------
|
||||
|
||||
While the Qubes developers support the statement above, some Qubes users may wish to enable user/root isolation in VMs anyway.
|
||||
We do not support this in any of our packages, but of course nothing is preventing a user from modifying his or her own system.
|
||||
A list of steps to do so is provided in the [Qubes community guide, Replacing passwordless root with a dom0 prompt
|
||||
](https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074) **without any guarantee of safety, accuracy, or completeness.
|
||||
An alternative approach is to enable user/root isolation by using a dom0 generated prompt.
|
||||
A list of steps to do so is provided in the [Qubes community guide, Replacing passwordless root with a dom0 prompt](https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074) **without any guarantee of safety, accuracy, or completeness.
|
||||
Proceed at your own risk.
|
||||
Do not rely on this for extra security.**
|
||||
|
||||
Dom0 passwordless root access
|
||||
-----------------------------
|
||||
|
||||
There is also passwordless user->root access in dom0.
|
||||
As stated in the comment in sudo configuration there (which is different from the one in individual qubes), there is really no point in user/root isolation, because all the user data (and VM management interface) is already accessible from dom0 user level, so there is nothing more to get from dom0 root account.
|
||||
There is also passwordless user->root access in dom0.
|
||||
As stated in the comment in `/etc/sudoers.d/qubes` there is really no point in user/root isolation in dom0, because all user data (and the whole Qubes management interface) is already accessible to the user, so there is nothing more to be gained from the dom0 root account.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue