On 7/27/14, intrigeri <intrigeri@???> wrote:
> Hi,
>
> [Re-adding Kill Your TV in the loop, again. kytv, you might want to go
> read Jake's message in the list archive.]
>
> 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?
I think the answer is no with total isolation in theory but in
practice, I wonder if if this is correct? Can an attacker hold a
socket open or do something tricky with i2p that would be hard to do
with a normal browser?
>
>>> 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?
>
> I think we could allow the i2psvc user to talk to any host on the
> Internet, but *not* to local services (apart of those that it really
> needs to talk to) nor to the LAN.
>
Ok. That sounds interesting!
>> How shall we scope the audit? What do you have in mind?
>
> Everything that relies on privilege separation (see sudo
> configuration) could be worth looking it. In particular, I'm thinking
> of the incremental upgrades security design and implementation.
>
I'm happy to look at the sudo rules but I don't know very much about
the incremental upgrades. If you want to talk about it, I'm certainly
open to looking into it.
>>>> 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?
>
> No, I was only mentioning the firewall rules that allow the amnesia
> user to talk to various local I2P services, and asking for what you
> were meaning by "a lot of permissive behavior" exactly.
Ah, OK. Understood.
>
> In passing, good news: if we go for "users have to opt-in for I2P in
> the Greeter, or -- first step -- on the kernel command-line", then we
> can drop this sudo rule entirely, and have I2P start automatically in
> some other way, when opted-in for.
>
Sure. That sounds fine. Though when I2P does start - we'd isolate it
with Tor? If so, I think this is a fine design but perhaps not the
best thing for the I2P world. :(
>>>> 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? :-)
>
> It seems we're not understanding each other on that one. Let me
> clarify what I meant:
>
> If I2P is running, then yes, escalating to i2psvc may be easier than
> escalating to debian-tor. But then, we do need these firewall rules,
> so "disabling the i2psvc firewall rules unless a user positively
> affirms that they want to run i2p" won't help in this case.
Hrm. If I2P is running because the user launched it (eg: at the
greeter), I agree. If I2P is running because of an attacker, I
wouldn't agree. Then the firewall *would* help stop such an attack. It
is reasonable defense in depth.
>
> If I2P is not running, then even bugs in I2P can't help escalating to
> the i2psvc user, while bugs in a few areas can help escalate to
> debian-tor. So, I'm not convinced that "disabling the i2psvc firewall
> rules unless a user positively affirms that they want to run i2p"
> would help much here either.
>
I disagree in practice - if someone can pop a shell as the Amnesia
user, they can jump to the i2psvc by using the sudo rule and then
attacking I2P. That concern seems to point toward a different
solution. Furthermore, it suggests that an actual I2P user should not
be so easy to deanonymize. That won't come from the firewall
protection, I guess.
> So, in both cases, I fail to see what this approach brings us in
> practice. I hope I was clearer. I'm not trying to convince you, but to
> try to make sure we're talking of the same thing, so that we can
> better understand each other :)
>
Sure - that is much clearer - hopefully my reply also clarifies why I
think it isn't just a single choice. :)
> But anyway, again: it seems to be a good security-in-depth mid-term
> goal, and I'd be happy to take good patches that implement it.
>
Ok. I think once we agree on what to do, I will help.
>>>> 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?
>
> I would not say "have stopped", but "have mitigated", and then my
> answer would be "yes, most likely" -- although I've never tried to
> write AppArmor confinement profiles for Java apps, so I might
> be wrong.
>
Ok. That is good - I'm not sure how we'd sandbox it without
*disabling* some of the features of I2P.
> 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.
>
>>>> I think this is probably not a wise idea. I really suggest a hotfix
>>>> for all users as soon as possible.
>> [...]
>> Is it possible to ship an update with one package or something similar
>> without shipping a new ISO?
>
> That won't be a "hotfix for all users".
>
>
> Details: once I2P 0.9.14 is ready for us, replacing the current
> security advisory with another one, that advices to upgrade the i2p*
> packages, would be easy, and not too much work. But then, it only
> benefits users who do it every time they start Tails, or use the
> additional software package persistence feature. So, it doesn't seem
> to be an adequate solution to the need you were expressing.
>
OK. I think I agree.
>>> 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. :(
>
> We're clearly not understanding each other on that one. I'm sorry my
> words lead you to think that I don't see the efforts you've been
> doing. I acknowledge you're putting quite some energy into this.
> What I see you're doing, and trust you'll do, it:
>
Oh - I don't mean to suggest that you need to acknowledge anything - I
was merely expressing that I hope someone *else* provides a better
patch and soon. I feel totally appreciated! :)
> 1. helping design good mid/long-term solutions in this thread
> 2. "I'm happy to try to review such fixes"
> 3. proposing a patch that removes I2P
>
> All this is great, but it won't give us an implementation of the
> security design we'll come up with. If you also volunteered to
> implement it, well then I'm very sorry, 'cause I've missed it.
>
Once we agree on a design and I can build the ISO, I will help
implement it, yes.
> In the sentence of mine that you're quoting, my point was to clarify
> what will impact whether (and when) we can/want to take the patch you
> provided:
>
> * if I2P folks or anyone are ready to put quite some energy into
> implementing a good security design for I2P-in-Tails, say, in time
> for Tails 1.2, then it would be sad to drop I2P entirely for Tails
> 1.1.1. We could change things so that I2P is functional only if
> some option is passed on the kernel command-line; most potential
> deeper counter-measures would probably be too invasive for
> a point-release, but perhaps a few baby-steps can be walked in
> time for the freeze (August 12);
>
Ok.
> * otherwise, then I think we should seriously consider applying your
> patch that entirely removes I2P.
>
Ok - if we have no energy from anyone else to help out, I think this
makes the most sense. It specifically makes sense to say that there is
a clear path to re-inclusion: we need to include it by having a more
secure design with AppArmor and other things that we've discussed.
>>>> 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.
>
>> Does that really fix the issue? Or does it merely shift it around? ( I
>> think you sorta touch on this issue below.... )
>
> It raises the bar only. I'm not aware of any way one can really
> protect GUI applications from the user running the desktop they run
> on, with the current design of X.
>
I'd like to require GUI actions, if possible. I like that the unsafe
browser for example requires user interaction. I realize that if
someone has code execution on the box, they can click through the UI.
That seems better than nothing though!
>>> 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.
>
> It's not that Vidalia (or any other X application we run as
> a dedicated user in Tails) has issues per-se, it's rather that Vidalia
> needs access to the Tor control port to do anything useful, and then
> this may cause problems. E.g. assuming the `amnesia' user is able to
> control Vidalia (that's been running as a dedicated user for a while)
> via X trickery, they can probably e.g. configure a carefully crafter
> set of bridges, and then de-anonymize the user. See #7072. And, once
> you start adding this to your threat model, then our other X apps run
> as a dedicated user may have problems too.
>
Yes, that is true. Though I think in the case of Vidalia, we've done
nearly everything possible to sandbox it.
>> If it was unfixable, we'd probably remove it entirely, no?
>
> See #6841 for the blockers.
>
This is a different kind of problem but still a problem, I think.
Vidalia is unmaintained but it isn't currently a security problem.
Long term, we need a different solution for sustainability, of course.
>> 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?
>
> As explained earlier and clarified above, my personal take on this
> depends on what the chances are that these issues are resolved, and
> what's the expected timeline for it.
>
Ok. I agree. I hope we'll have an idea in the next few days.
All the best,
Jacob
