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
Some applications complains if compiled version of dconf database is
missing ("dconf-WARNING **: unable to open file '/etc/dconf/db/local':
Failed to open file '/etc/dconf/db/local': open() failed: No such file
or directory; expect degraded performance").
There is only one entry in that database, but generate its binary
version anyway to avoid that warning message.
The dconf call is already included in package scripts, now only make
sure the utility is really installed.
QubesOS/qubes-issues#1951
The /etc/dconf/profile/user file in some distributions is part of dconf
package, in some not. There are even cases where it changes between
package versions (Fedora 27 don't have it, but Fedora 28 do).
Also, base Debian Stretch don't have it, but Kali Linux based on it do.
To avoid overly complex dependency handling, create the file dynamically
on package installation if it's missing in that particular case. The
file content is canonical:
user-db:user
system-db:local
FixesQubesOS/qubes-issues#3834
- BACKEND_VMM may not be available as env variable (mock build), provide
it explicitly
- 'user' group may not exists at package build time, set it at package
installation
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
It doesn't make sense in Qubes to rebuild modules at every VM startup.
Especially when modules dir is either read-only, or on non-persistent
root volume (TemplateBasedVM).
This is especially uneeded for dom0-provided kernels, which already have
u2mfn module built, but DKMS try to rebuild it anyway (and fails,
because of missing/broken kernel-devel package).
DKMS already have appropriate (rpm/dpkg) hooks for new kernel
installation, so actually needed modules should be build in template on
kernel update/install anyway.
This saves about 2s from VM startup time.
If IPv6 gateway address provided by dom0 isn't a link local address, add
a /128 route to it. Also, add this address on backend interfaces (vif*).
This is to allow proper ICMP host unreachable packets forwarding - if
gateway (address on vif* interface) have only fe80: address, it will be
used as a source for ICMP reply. It will be properly delivered to the VM
directly connected there (for example from sys-net to sys-firewall), but
because of being link-local address, it will not be forwarded any
further.
This results timeouts if host doesn't have IPv6 connectivity.
Since fixing QubesOS/qubes-issues#3213, launch function correctly waits
for some applications exit. This is undesirable for
qubes-session-autostart service, which should just start the
applications and exit.
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.
