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.
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).
This, combined with our stream isolation design, could raise the bar
a bit on this front.
>> 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.
> 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?
>> 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.
> 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 :)
>> * 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.
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.
> 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.
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.
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.
> 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).
> 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!
Cheers,
--
intrigeri
