This should avoid a race condition where we miss an update to QubesDB
that happens right after the initial load, but before the watch start.
Instead, we might now install the same stuff twice - but that's no
problem.
each handling iteration
Actually a counter is increased after each handling iteration.
This is useful for user applications to remain up to date with the
changes implemented by the Qubes firewall.
This can e.g. allow DNS applications to pin a FQDN to the IP
used during Qubes OS firewall setup.
Can help with QubesOS/qubes-issues#5225 and other related issues.
The whole distutils module is a legacy thing in python3. Specifically,
most of it is not installed in Debian by default (there is only
distutils.version). Depending on python3-distutils is problematic, as
it's availability varies between Debian versions.
Instead of fighting with special cases in dependencies, replace the
whole thing with non-legacy shutil.which() (available since Python 3.3).
Used by qubes.StartApp so that we can override distribution-provided
.desktop files. The mechanism is introduced to run gnome-terminal
with --wait option, so that it's compatible with DispVMs.
FixesQubesOS/qubes-issues#2581.
qubes-firewall will now blacklist IP addresses from all connected
machines on non-vif* interfaces. This prevents spoofing source or
target address on packets going over an upstream link, even if
a VM in question is powered off at the moment.
Depends on QubesOS/qubes-core-admin#303 which makes admin maintain
the list of IPs in qubesdb.
FixesQubesOS/qubes-issues#5540.
This part of GIO library isn't suitable for short-lived processes (the
call is done asynchronously and may not reach the application before
qubes-desktop-run process is terminated). To fix this, implement dbus
activation manually, synchronously.
While at it, implement waiting for application to terminate (useful in
DispVM), by waiting for its dbus name to disappear.
dbus-python API isn't particularly nice, but don't switch to completely different
library as a stable update.
FixesQubesOS/qubes-issues#2449
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
