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?
>> 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.
> 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.
>>> 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.
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.
>>> 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.
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.
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 :)
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.
>>> 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.
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.
>>> 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.
>> 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:
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.
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);
* otherwise, then I think we should seriously consider applying your
patch that entirely removes I2P.
>>> 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.
>> 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.
> If it was unfixable, we'd probably remove it entirely, no?
See #6841 for the blockers.
> 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.
Cheers!
--
intrigeri
