On 7/26/14, intrigeri <intrig...@boum.org> 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 <intrig...@boum.org> 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 _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.