Re: [Tails-dev] What to do about I2P in Tails?

Hi,

(Note: I'm dropping parts of the discussion that are made moot thanks
to Kill Your TV's branch: it's too late to discuss if it would be
worth doing $this or not, when the work has already been done, and the
code seems close to be mergeable :)

Jacob Appelbaum wrote (27 Jul 2014 14:24:53 GMT) :
> On 7/27/14, intrigeri <intrigeri@???> wrote:
>> Jacob Appelbaum wrote (27 Jul 2014 02:13:43 GMT) :
>>> On 7/26/14, intrigeri <intrigeri@???> wrote:
>>>> Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) :
>>>>> A compromose of i2p is game over on Tails from an anonymity
>>>>> perspective.
>>>>
>>>> This is not so obvious to me: I2P activity could possibly be
>>>> de-anonymized, without being trivially linkable to the torified
>>>> activity.
>>
>>> I think that seems incorrect. If a user visits a hostile web page
>>> served to a Tor exit... wouldn't they be able to tag that user? I
>>> think so.
>>
>> I'm sorry I don't get what you mean here. Could you please elaborate?

> I mean - if someone serves you an i2p site in an iframe over an evil
> exit, what happens? Is there any difference? Can you do something
> nasty to them? Can you correleate other streams/circuits in any way?

Ah, I see. My point above ("could possibly [...]") was about how
things would be if we isolated I2P traffic better, e.g.
with a dedicated web browser. Sorry for being unclear, and thanks for
clarifying your point, which I do agree with, as long as Tor and I2P
web browsing can be freely mixed.

> Ok. That is good - I'm not sure how we'd sandbox it without
> *disabling* some of the features of I2P.

Yep, we'll see. Given it seems to be pretty consensual that we want to
sandbox I2P, and the I2P folks want to work on it, I've created #7724
to track it. I'll suggest to flag it for the 3.0 milestone in another
email dedicated to updating our roadmap.

>> Sandboxing can make it harder, for anyone who can exploit such an RCE
>> bug, and is able to run whatever they want as the i2psvc user, to take
>> advantage of it usefully. That's all sandboxing can provide. It may
>> not be much, but it's cheap and worth it IMO.

> Perhaps I2P can implement a unix socket for the control panel and then
> we can sandbox that process differently? Perhaps that doesn't make
> sense? I don't know.

Yes, perhaps. Do you already have something in mind regarding "sandbox
that process differently", that would take advantage of having
a Unix socket?

> Once we agree on a design and I can build the ISO, I will help
> implement it, yes.

Great! Kill Your TV is already on #7725 ("Isolate I2P web browsing
from Tor"), so what could be done is:

* to test Kill Your TV's branch for #7722 ("Make I2P harmless unless
enabled on the kernel command-line");

* to look for existing AppArmor profiles for I2P (#7724), and then,
depending on the results, either to improve it or to create new
ones; it's not possible to test this inside Tails yet, though (#6198);

* to audit the I2P implementation and packaging we use; I'm especially
concerned with the bundled code copies (look e.g. for jetty*.jar in
the source package), that get no security support from Debian.
Not checked I2P 0.9.14, but in 0.9.13, it's also lagging behind one
upstream version. If I2P really needs 8.1.14+, then "we" "should"
help the Debian Java Maintainers with the jetty8 package, and then
use the one from Debian instead of a bundled one we don't bother
checking the security status of in practice.

Cheers!
--
intrigeri