-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, May 23, 2024 at 12:33:02PM -0000, qubist wrote:
> On Thu, 23 May 2024 12:04:18 +0200 Marek Marczykowski-Górecki wrote:
>
> > I mean one of them will drop packets that would be allowed by the
> > other. So, no traffic will be allowed.
>
> Indeed. I will fix that.
>
> > Those are actually intentional, we don't do dynamic IP configuration
> > on purpose (attack surface reduction), and even if for some reason
> > one VM would try to sent such packets (could be an attempt to change
> > sys-firewall's configuration by one of AppVMs...), they should be
> > blocked. Same for Redirect.
>
> According to RFC 4890 section 4.4.1 (local configuration traffic),
> router advertisement messages (ICMPv6 type 134) must not be dropped by
> the end host (Qubes drops them). In 4.3.3 (transit traffic), they list
> both types (134 and 137) as "Traffic That Will Be Dropped Anyway -- No
> Special Attention Needed" and in the bash script in the appendix they
> actually drop them + quite a few other types - traffic which Qubes
> allows. So, except for type 137 (redirect), there is some significant
> discrepancy between these recommendations and Qubes.
There will be some intentional discrepancies, that document describes a
network using IPv6 autoconfiguration (where indeed packets like 133 and
134 are crucial), which we explicitly decide to not use.
> That, of course, is off-topic we can discuss later. I am just
> mentioning it along the lines of what should/not be dropped by the
> antispoof and its potential effect on IPv6.
>
> > Still, link-local addresses shouldn't be used to communicate between
> > two different links.
>
> If I am reading the RFC correctly, they are not used for communicating
> (i.e. fully-fledged data transfer), but rather for establishing
> communication. I am not a network expert, so I am not closely familiar
> with all the inner workings of IPv6.
>
> Section 6.1.2 of RFC 4861 says:
>
> - IP Source Address is a link-local address. Routers must use
> their link-local address as the source for Router Advertisement
> and Redirect messages so that hosts can uniquely identify
> routers.
>
> Assuming sys-firewall is the router, perhaps there needs to be a way to
> advertise it.
RD etc shouldn't really be needed in our case. But neighbor discovery
might.
> However, that is a data-collision problem because all
> qubes have the same link-local address and the node would confuse its
> own with that of sys-firewall. No?
No, link-local addresses don't need to be globally unique, they need to
be unique only within a scope of a _single_ link (eth0<->vif pair in
this case). Linux (or any other routing-capable OS for that matter)
needs to consider which interface to use for which control packet anyway
- - in fact, I think it's not valid to target link local address without
explicit interface name (on which link you want it to be). For example
ping warns about it:
$ ping6 fe80::fcff:ffff:feff:ffff
ping6: Warning: IPv6 link-local address on ICMP datagram socket may require
ifname or scope-id => use: address%<ifname|scope-id>
> > That said, allowing specific link-local address in the antispoofing
> > rules (and later filter undesirable packets using normal rules) might
> > be a good idea.
>
> My thoughts too. The question is what is the appropriate way to do
> this, considering that currently all MAC addresses are the same => all
> link-local IPv6 addresses too. IOW, what would be the mechanism of
> getting the specific link-local address, so that it can be used in the
> antispoofing rules?
Build it based on the qube MAC address (which should be known to the vif
script already)? Those antispoofing rules are meant only to prevent qube
using IP that it's not allowed to use. So, for IPv6 a qube would be
allowed to use either its "main" IPv6 or its link-local IPv6. Those
rules are not meant to ensure any uniqueness, and link-local addresses
don't need to be unique across different links.
> > > Are you suggesting that we should antispoof eth0 too?
> >
> > Yes, the change you propose should not regress one of the issues
> > classified as security bugs before...
>
> It does not propose that. It does not allow traffic which is blocked by
> current implementation.
Are you sure? The current implementation has this rule in prerouting:
ip saddr @downstream counter drop
and a matching "downstream" set. Your version removes that without
equivalent replacement.
> > For example, sys-net should not be able to pretend to be one of your
> > AppVMs. That's especially relevant if you'd configure sys-firewall to
> > allow traffic between some AppVMs.
I think you can do an experiment:
1. Create two qubes (I'll name them test1 and test2).
2. Add a rule in sys-firewall that would allow traffic from test2 to
test1 and vice versa:
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
3. Start test1 and observe incoming traffic on its eth0 (you may want to
clean its firewall for the experiment, to allow all).
4. Do _not_ start test2.
5. Try to spoof IP of test2 from sys-net - like, add to the vif interface
going to sys-firewall and try to use as a source when pinging test1 from
there.
This should normally be blocked, but I think your version won't block
it.
> In my mentioned bigger firewall hardening setup, which may probably fit
> better in a separate thread, I have this:
>
> table netdev hardening {
> chain ingress {
> type filter hook ingress device "eth0" priority -500;
> ip saddr @bogons_ipv4 counter drop
> ip6 saddr @bogons_ipv6 counter drop
> # ... fragments handling
> # ... early invalid drop
> # ... TCP MSS segment filtering
> # ... SYN tarpit
> }
> # ...
> }
>
> and the sets are populated using:
>
> https://team-cymru.org/Services/Bogons/fullbogons-ipv4.txt
> https://team-cymru.org/Services/Bogons/fullbogons-ipv6.txt
>
> Qubes' internal IP addresses are covered by these lists.
Well, this is too broad, as for example sys-net is allowed to use its
own IP to send packets down the network (like to sys-firewall or other
qubes). This happens for example for ICMP error packets. It would also
break any communication to your LAN (like, using network printer in your
LAN)...
This list may work on internet-only router without any kind of LAN
involved only.
> > Sure: https://www.qubes-os.org/doc/automated-tests/
> > For network specifically, there is qubes.tests.integ.network
> > and qubes.tests.integ.network_ipv6.
>
> Thanks. This is somewhat complicated for me.
It is a bit (at least for the first time). The tl;dr is:
sudo systemctl stop qubesd; sudo -E python3 -m qubes.tests.run
qubes.tests.integ.network; sudo systemctl start qubesd
But note it will remove any qube with name starting with "test-" prefix.
Anyway, that's why I asked for a PR, as we have scripts doing this all
automatically.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZPSmMACgkQ24/THMrX
1yxXsAf9HDxIJQdd8LVWEOb4FmrLNZAr8FLxK7FTE/2OrUBloQWNxtWvpdy3vZ4i
5EMT1vGetm5PgJrVi8M/5tiRjJHbYRsPMknXPojtYkL+D5d/2ymS2sKRPAmCbduw
QItUMLLNkbtNixm1dOBbpdDPmguw20bd0G5+cIK0dFj7tYcYNK59mNY861eAd6Bb
CuY8dkcKnAndaRApV3ouF0UIQjgxgEYU+tKOLDzem+FroTWuKKzlGbXc+1rOICPb
F4YWnwPoyZedwLsMZznfedxmgF3Nz777ivXzDz4s5qTkndYGlnDMw/ONdqyoMMkl
9QMxaEN/Dm2bo2bBdO1PJwktk8twzw==
=+6DR
-----END PGP SIGNATURE-----
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/Zk9KY0C-pcSiwSzP%40mail-itl.
