Both Archlinux and Fedora 29 have guidelines to point explicitly at
/usr/bin/python2 where it expect python2.
Also, do not use env.
FixesQubesOS/qubes-issues#4027
I've run into an issue with incorrectly generated rules for IPv6. I
added some debugging code printing the generated rules and the
resulting error (see below). Turns out "reject with" expects icmpv6
rather than icmp6.
--- generated rule ---
flush chain ip6 qubes-firewall qbs-fd09-24ef-4179--a89-15
table ip6 qubes-firewall {
chain qbs-fd09-24ef-4179--a89-15 {
ip6 daddr fc00::/8 reject with icmp6 type admin-prohibited
ip6 daddr fd00::/8 reject with icmp6 type admin-prohibited
ip6 daddr fe80::/10 reject with icmp6 type admin-prohibited
accept
reject with icmp6 type admin-prohibited
}
}
--- output ---
/dev/stdin:4:36-40: Error: syntax error, unexpected string, expecting icmp or icmpv6 or tcp or icmpx
^^^^^
/dev/stdin:5:36-40: Error: syntax error, unexpected string, expecting icmp or icmpv6 or tcp or icmpx
^^^^^
/dev/stdin:6:37-41: Error: syntax error, unexpected string, expecting icmp or icmpv6 or tcp or icmpx
^^^^^
/dev/stdin:8:17-21: Error: syntax error, unexpected string, expecting icmp or icmpv6 or tcp or icmpx
^^^^^
qubes-firewall service is meant as mistakes mitigation, not a
high-volume external network filter. Providing feedback (ICMP
admin-prohibited error packet) to the VM reduces timeouts and give
immediate connection failure. This is especially useful when some
website tries to load unwanted (not whitelisted) 3rd party elements -
providing error response avoids long site loading time.
FixesQubesOS/qubes-issues#3607
qubes-firewall.service have Before=qubes-network.service. The latter
enable ip_forwarding. Make sure the ordering cover not only service
fork, but all its startup sequence, including initial rules and user
scripts.
Reported-by: @tasket
This is especially important for qubes-desktop-run used inside DispVM.
The DesktopAppInfo.launch() method returns after just launching the
application. In DispVM case it worked by a coincidence - because the
launched application was keeping stdin/out open, which also prevented
DispVM killing. Use DesktopAppInfo.launch_uris_as_manager which at least
allows to learn PIDs of spawned processes, to track them manually.
This still doesn't fix gnome-terminal issue, or any other application
using either DBus activation, or any other client-server model. But at
least fix basic apps like firefox and xterm.
FixesQubesOS/qubes-issues#3213
Since we have proper python package, use it instead of hacky one-file
package. This will ease installation and packaging, including switching
to python3.
Call it just after creating base chains in iptables/nftables. This allow
the user to modify how those rules are plugged in, add custom rules at
beginning/end etc.
FixesQubesOS/qubes-issues#3260
Chain name in IPv6 cannot be longer than 29 chars, so strip IPv6 prefix
from it.
ICMP on IPv6 is a different protocol than on IPv4 - handle iptables rule
accordingly.
QubesOS/qubes-issues#718
When qubes-firewall service is started, modify firewall to have "DROP"
policy, so if something goes wrong, no data got leaked.
But keep default action "ACCEPT" in case of legitimate service stop, or
not starting it at all - because one may choose to not use this service
at all.
Achieve this by adding "DROP" rule at the end of QBS-FIREWALL chain and
keep it there while qubes-firewall service is running.
FixesQubesOS/qubes-issues#3269
This rewrite is mainly to adopt new interface for Qubes 4.x.
Main changes:
- change language from bash to python, introduce qubesagent python package
- support both nftables (preferred) and iptables
- new interface (https://qubes-os.org/doc/vm-interface/)
- IPv6 support
- unit tests included
- nftables version support running along with other firewall loaded
FixesQubesOS/qubes-issues#1815QubesOS/qubes-issues#718
