On 7/26/14, intrigeri <intrigeri@???> wrote:
> Hi,
>
> [Re-adding Kill Your TV in the loop. kytv, you might want to go read
> Jake's message in the list archive.]
>
> Jacob Appelbaum wrote (25 Jul 2014 11:56:05 GMT) :
>> On 7/25/14, intrigeri <intrigeri@???> wrote:
>>> So, the main goals I have in mind are:
>>>
>>> 1. making it harder, for an attacker who compromises I2P running in
>>> Tails, to upgrade their attack to anything non-I2P;
>
>> 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.
Also - note - I said a compromise - that is RCE on Tails and not just
a direct connection...
>
> E.g. we could forbid I2P to talk to anything it should not talk to
> (the Tor ports spring to mind, but obviously a whitelist approach
> would be better; and BTW, symetrically, the debian-tor user should
> only need to talk to the Internet, and to proxies on the LAN if
> configured to use one).
>
I'm not sure that I understand the I2P protocol well enough to know
how to define such a boundary. What should it talk to? What shouldn't
it talk to?
> This, combined with our stream isolation design, could raise the bar
> a bit on this front.
>
Perhaps so. I want to say that it can't be worse than the current
setup but I wonder if that is true.
>>> 3. protecting the Tails users who don't intend to use I2P at all,
>>> from vulnerabilities in I2P, by making it harder, for an attacker,
>>> to start I2P in Tails, or to trick a user into doing it.
>
>> I think that means we need to audit the default state of the system
>> even if we're not running i2p.
>
> Agreed.
>
How shall we scope the audit? What do you have in mind?
>> The system is ready for i2p to run and
>> as a result, it has a lot of permissive behavior that is not strictly
>> required.
>
> I see the firewall rules that grant i2psvc full access to the network,
> the FoxyProxy configuration, and the fact the amnesia user can talk to
> I2P in many ways. Does "a lot of permissive behavior" include anything
> else I've missed?
>
I'm not sure? The sudo rules ( /etc/sudoers.d/zzz_i2p ) seem
rather... excessive but perhaps that is what you meant about "the
amnesia user can talk to I2P in many ways" - I'm not sure?
>>> Regarding #1:
>>>
>>> a) On the filesystem and privilege escalation side, I think we should
>>> sandbox I2P better. We're working on integrating AppArmor in
>>> Debian and Tails, and I think I2P would be a good candidate for
>>> confinement. @I2P folks: do you already have anything in the works
>>> in this area? Anyone else?
>>>
>
>> I would say that we should disable the i2p rules in the firewall
>> unless a user positively affirms that they want to run i2p. As it
>> stands now - there is a full user that is able to talk to the
>> internet, regardless of the state of i2p.
>
> I'm not sure why escalating privileges to i2psvc would be any easier
> than escalating to debian-tor (especially given the latter is running
> stuff and talking to the network already anyway). Still, I agree this
> would be a good security-in-depth mid-term goal.
What about the recent I2P bug? Seems much easier unless you've got
some Tor 0day up your sleeve? :-)
>
>> I think torifying i2p is a fine middle ground for accessing i2p
>> services. [...] Still - it isn't enough. Code execution in i2p as
>> detailed
>> on the Exodus blog would not be stopped by Torification of i2p. The
>> impact of such a bug would not be completely minimized either -
>> arbitrary code on the system can still read out unique identifiers.
>
> Sure. This is why I raised the sandboxing topic :)
>
Does I2P still function when sandboxed in a way that would have
stopped that RCE bug?
>>> * If we keep I2P without adding any protection immediately, when do
>>> we expect *which* protections to be ready? (reality check: we won't
>>> have AppArmor before October; I guess the Greeter won't be ready
>>> earlier either)
>
>> I think this is probably not a wise idea. I really suggest a hotfix
>> for all users as soon as possible.
>
> Our advisory (security/Security_hole_in_I2P_0.9.13) that all Tails
> users now see on every boot explains how to protect oneself, to
> various extends, depending how strongly they feel about it. Granted,
> it's a bit painful, but once balanced with how much energy is
> currently required to put a release out, I think I'd rather see us
> work on streamlining our release process, than kill ourselves with an
> additional emergency release.
Is it possible to ship an update with one package or something similar
without shipping a new ISO?
>
> Still, for 1.1.1, the question is left open, and I'm unsure what my
> take on it is. I think my level of comfort wrt. keeping I2P and
> waiting for proper solutions will strongly depend on what kind of
> energy I see arising to actually design and implement these solutions.
>
I've already provided a patch to completely remove I2P as a hotfix.
I'm not thrilled if that is the only effort you see beyond emails. I
really hope to be outdone here. :(
>> Part of my concern here is the router console. If amnesia can access
>> it, it can effectively do whatever i2p's user can do, right?
>
> Yes, most likely.
Ok. That confirms my concerns.
>
> My proposal was that the `amnesia' user is not allowed to talk to that
> console anymore, but instead a dedicated user (that runs a dedicated
> I2P web browser) is.
Does that really fix the issue? Or does it merely shift it around? ( I
think you sorta touch on this issue below.... )
>
> Of course, via X trickery, `amnesia' will still be able to do so, but
> once you open this box, much of our privilege separation design (e.g.
> for tails-persistence-setup, incremental upgrades, and Vidalia) has
> problems. I'm not saying we should act as if this problem did not
> exist, but it's far from being specific to I2P, and I doubt we'll have
> a sane and maintainable solution to it before we migrate to Wayland.
> Even the great X security improvements that come with logind can't
> address this, unfortunately.
Well, if we knew say... that Vidalia had similar issues - we would
probably isolate it very seriously. If it was unfixable, we'd probably
remove it entirely, no?
>
>> I've provided a patch privately to resolve this issue but it isn't
>> perfect by any means. Is this patch being considered?
>
> I'm personally not considering this patch before the discussion
> started in this thread happens, we get some idea of how we
> collectively feel about all this, and the questions I asked get
> answers from the folks interested in working on I2P integration in
> Tails (I guess they're busy with releasing I2P 0.9.14 right now, so it
> may take some time).
Is there anyone who wants Tails to ship I2P? Or asked another way:
would anyone object to not shipping I2P before we resolve the issues
that you've (or rather that we have) raised?
>
>> I don't feel too strongly about it - I merely wanted to contribute
>> something helpful during the stressful evening.
>
> ... and I do appreciate it very much. Thanks!
Glad to hear it. This issue lit a fire under me to help out a lot more
with Tails.
All the best,
Jacob
