Qubes/gsoc
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Project update

Browse Source
This commit is contained in:
Giulio 2021-08-16 22:22:25 +02:00
parent 9589a9fe49
commit c3a1c7637f
1 changed files with 68 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

98
Readme.md
View File

@ -13,6 +13,8 @@ First develop and document the part related to manual port forwarding since it i
1. https://github.com/QubesOS/qubes-issues/issues/3556 1. https://github.com/QubesOS/qubes-issues/issues/3556
2. https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/ 2. https://www.reddit.com/r/Qubes/comments/8cb57i/how_to_achieve_qube_to_qube_communication_port/
3. https://github.com/QubesOS/qubes-issues/issues/6225 3. https://github.com/QubesOS/qubes-issues/issues/6225
4. https://github.com/QubesOS/qubes-issues/issues/5031
5. https://gist.github.com/fepitre/941d7161ae1150d90e15f778027e3248
## Development ## Development
### Background ### Background
@ -23,10 +25,11 @@ First develop and document the part related to manual port forwarding since it i
* https://www.qubes-os.org/doc/config-files/ * https://www.qubes-os.org/doc/config-files/
### Dev Repositories ### Dev Repositories
* https://git.lsd.cat/Qubes/core-admin * https://github.com/lsd-cat/qubes-core-admin
* https://git.lsd.cat/Qubes/core-admin-client * https://github.com/lsd-cat/qubes-core-admin-client
* https://git.lsd.cat/Qubes/core-agent-linux * https://github.com/lsd-cat/qubes-core-agent-linux
All changes are in the `gsoc-port-forwarding` branch of each repo.
### Main components involved ### Main components involved
1. [Firewall GUI in "Settings" (qubes-manager)](https://github.com/QubesOS/qubes-manager/blob/master/qubesmanager/firewall.py) 1. [Firewall GUI in "Settings" (qubes-manager)](https://github.com/QubesOS/qubes-manager/blob/master/qubesmanager/firewall.py)
@ -133,7 +136,9 @@ Of course `expire=` and `comment=` are optional fields.
<property name="comment">example https server rule</property> <property name="comment">example https server rule</property>
</properties> </properties>
</rule> </rule>
``` ```Sorry. We’re having trouble getting your pages back.
We are having trouble restoring your last browsing session. Select Restore Session to try again.
### Proposal chart ### Proposal chart
###### The main distinction between internal and external port forwarding is: ###### The main distinction between internal and external port forwarding is:
@ -165,53 +170,86 @@ options as the point above
here. Here there is the need to resolve the full network chain for here. Here there is the need to resolve the full network chain for
external port forwarding. From here it is possible to add the respective external port forwarding. From here it is possible to add the respective
rules to the QubesDB of each NetVM in he chain and trigger a reload event. rules to the QubesDB of each NetVM in he chain and trigger a reload event.
4. 🚧 In `core-agent-linux/qubesagent/firewall.py` -> Here goes the logic for 4. ✔️ In `core-agent-linux/qubesagent/firewall.py` -> Here goes the logic for
building the correct syntax for iptables or nft and the actual execution building the correct syntax for iptables or nft and the actual execution
5. ❌ GUI 5. ❌ Tests
6. ❌ Tests 6. ❌ GUI
Both tests and GUI have yet to be worked on. Automated tests will be written soon in the following weeks.
### Required rules ### Required rules
#### External #### External
The iptables backend in the firewall worker is being deprecated. If the `nft` binary is available on the target Qubes, iptables will be never involved. Thus, only `nft` rules are relevant in this context.
***srchost and srcports support yet to be written here *** Sample setup:
In `<networkvm>`:
``` ```
iptables -t nat -A PREROUTING -i <external_iinterface> -p tcp --dport <target_port> -d <interface_ip> -j DNAT --to-destination <firewallvm_ip> sys-net - 10.137.0.5 (ens6 phy with 192.168.10.20)
iptables -I FORWARD 2 -i <external_iinterface> -d <firewallvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT sys-firewall - 10.137.0.6
nft add rule ip qubes-firewall forward meta iifname <external_iinterface> ip daddr <firewallvm_ip> tcp dport <target_port> ct state new counter accept personal - 10.137.0.7
``` ```
In `<firewallvm>`: All of them are running fedora-32.
``` And assume the following rule added via qvm-firewall:
iptables -t nat -A PREROUTING -i <interface> -p tcp --dport <target_port> -d <firewallvm_ip> -j DNAT --to-destination <appvm_ip>
iptables -I FORWARD 2 -i <interface> -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT ```# qvm-firewall personal add action=forward forwardtype=external scrports=22-22 proto=tcp dstports=2222-2222 srchost=192.168.10.0/24
nft add rule ip qubes-firewall forward meta iifname <interface> ip daddr <appvm_ip> tcp dport <target_port> ct state new counter accept
``` ```
in `<appvm>`: First, a table for the forwarding rules is created:
```
iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT
```
#### Internal
In `<firewallvm>`:
``` ```
iptables -t nat -A PREROUTING -i <interface> -p tcp --dport <target_port> -d <firewallvm_ip> -j DNAT --to-destination <appvm_ip> flush chain {family} qubes-firewall-forward prerouting
iptables -I FORWARD 2 -i <interface> -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT flush chain {family} qubes-firewall-forward postrouting
nft add rule ip qubes-firewall forward meta iifname <interface> ip daddr <appvm_ip> tcp dport <target_port> ct state new counter accept table {family} qubes-firewall-forward {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
masquerade
}
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
}
}
``` ```
in `<appvm>`: Then, if the qube is marked as 'last', meaning that it is the external qube with the physical interface the following rules are added:
``` ```
iptables -w -I INPUT 5 -d <appvm_ip> -p tcp --dport <target_port> -m conntrack --ctstate NEW -j ACCEPT table {family} qubes-firewall-forward {
chain prerouting {
meta iifname "ens6" {family} saddr 192.168.10.0/24 tcp dport {{ 22 }} dnat to 10.137.0.6:2222
}
}
table {family} qubes-firewall {
chain forward {
meta iifname "eth0" {family} daddr 10.137.0.6 tcp dport 2222 ct state new counter accept
}
}
``` ```
And that is all for sys-net.
In sys-firewall, since it is an 'internal' qube, the following rules are added instead:
```
table {family} qubes-firewall-forward {
chain prerouting {
meta iifname "eth0" {family} saddr 120.137.0.5 tcp dport {{ 2222 }} dnat to 10.137.0.7:2222
}
}
table {family} qubes-firewall {
chain forward {
meta iifname "eth0" {family} daddr 10.137.0.7 tcp dport 2222 ct state new counter accept
}
}
```
Lastly, some rules need to be added in the target Qube in order to accept the incoming connections. Since the target Qube does not have a running firewall worker, the method for doing this has yet to be determined.
## Extra ## Extra
### QubedDB Debugging ### QubesDB Debugging
Since all firewall rules are written to the respective domains QubesDB by the `qubesd` it is essential dor debugging purposes to be able to easily read QubesDB entries. The QubesOS Project provide some useful utilities to interact with each DB. Such utilities have self explicative names and works like the respective functions used in the source code. The most useful are: Since all firewall rules are written to the respective domains QubesDB by the `qubesd` it is essential dor debugging purposes to be able to easily read QubesDB entries. The QubesOS Project provide some useful utilities to interact with each DB. Such utilities have self explicative names and works like the respective functions used in the source code. The most useful are: