On Tue, 12 Aug 2014 16:20:57 +0000 (UTC)
intrigeri <intrigeri@???> wrote:
> Nice catch! I suspect it would be the same if we kept this commit's
> change to the OUTPUT chain (that explicitly rejects packets anyway),
> and added an explicit reject rule to the INPUT chain for packets as
> the loopback interface (both source and destination). Care to
> try that?
Assuming I understood the request properly, I tried the following:
a/config/chroot_local-includes/etc/ferm/ferm.conf +++
b/config/chroot_local-includes/etc/ferm/ferm.conf @@ -179,6 +179,7 @@
domain ip6 { table filter {
chain INPUT {
policy DROP;
+ daddr ::1 saddr ::1 REJECT;
}
chain FORWARD {
which had this result:
# ip6tables -vnL
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination 0 0 REJECT all *
* ::1/128 ::1/128 reject-with
icmp6-port-unreachable
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source
destination 14 1456 LOG all *
* ::/0 ::/0 LOG flags 8 level 7
prefix "Dropped outbound packet: " 14 1456 REJECT all *
* ::/0 ::/0 reject-with
icmp6-port-unreachable
No traffic over the INPUT chain, and of course, it still hangs.
> But I'd like to see the root
> cause of the much increased hang time fixed as well, so that we're not
> 1. adding layers over layers of workarounds; 2. exposing ourselves to
> other similar regressions caused by the new, stricter IPv6 firewall.
Absolutely!
> >> Any idea why I still see the firewall blocking attempts to talk to
> >> CUPS, even with your fix applied? Can you reproduce this?
>
> > It's reproducible here. It always tries to communicate with CUPS via
> > IPv6, even with my simple change, only with my change it doesn't
> > block the Print window from appearing. According to mozillazine's
> > KB[0], my change of setting "print.postscript.cups.enabled" to
> > "false" 'should' stop it from trying to access CUPS, so maybe this
> > is a Firefox bug?
>
> Seems like it is. Want to reproduce it with a pristine Firefox, and
> then report upstream?
I plan on trying it with Iceweasel in Debian proper and with an ESR
binary from Mozilla.
--
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A
