Re: [Tails-dev] [review'n'merge 1.?] Bug #7771: printing in …

Delete this message

Reply to this message
Autor: Kill Your TV
Data:  
Para: tails-dev
Assunto: Re: [Tails-dev] [review'n'merge 1.?] Bug #7771: printing in unsafe-browser leads to browser hang
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