03/09/13 18:53, intrigeri wrote:
> Hi,
>
> sajolida@??? wrote (31 Aug 2013 14:00:08 GMT) :
>> A Whisperback bug report is suggesting us to limit the user i2psvc to
>> send UDP through the firewall.
>
> Looks mostly good (once it has comments), only one question below.
>
>> Here is a patch for that.
Unfortunately the premise of this patch is wrong; I2P uses *both* UDP
and TCP transport over the "clear" Internet [1]. If anything this change
will make Tails I2P clients stand out.
[1]
http://www.i2p2.de/protocols.html (see the "Transport layer" bullet)
>> It also adds missing ports 7654 7658 for the
>> user amnesia to access some i2p services.
>
> Once some commit message tells me what problem this solves, and what
> "some i2p services" are, then I'm happy to review this part.
> The design doc would need an update, likely, but this can probably
> wait for a future iteration.
For the record, the I2P FAQ has a comprehensive list of all ports (local
and external) used by I2P:
http://www.i2p2.de/faq.html#ports
TCP lo port 7654 is for I2CP [1], a client protocol, that no application
shipped in Tails depends on. I don't see any harm in white-listing it,
but it'll only be useful for users that actually install some
(non-supported) application that uses I2CP, and hence I don't see much
of a reason to either.
[2]
http://www.i2p2.de/i2cp
TCP lo port 7658 gives local access to the I2P web server that can be
enabled to serve a personal eepsite (i.e. it's akin to a http Tor hidden
service), but a placeholder site is shown it's disabled. Note that the
I2P webserver is disabled by default in Tails. I suppose this would be
handy for users that enable it, but I'm not sure we want to support
that, especially since we're in hidden mode.
>> + outerface ! lo mod owner uid-owner i2psvc {
>> + proto udp ACCEPT;
>> + }
>
> Any specific reason to only restrict on !lo?
> In other words, does I2P need to do TCP on the loopback interface?
I2P doesn't start any UDP lo listeners so such a restriction looks like
a valid firewall lockdown step. I think i2psvc at least needs access to
the service wrapper (TCP lo port 32000+, the first free one) for being
able to shut down cleanly.
---
While the above makes it clear that there's room for some more
fine-grained white-listing of which lo ports i2psvc (and debian-tor for
that matter) can access, I sadly think there's nothing in this patch
really worth merging at this point. Sorry, anonymous contributor. :(
Cheers!
