Re: [Tails-dev] vpwned + greeter

On 03/11/14 23:42, Jurre van Bergen wrote:
> On 11/02/2014 12:48 AM, intrigeri wrote:
>> Hi,
>>
>> Jacob Appelbaum wrote (24 Jul 2014 01:16:26 GMT) :
>>> I've waited a while for folks to read it and I think at this point,
>>> we're at year two or so of waiting. It seems like the easy thing is to
>>> simply give up and advocate for a fix with a simple patch.
>> I have to admit I'm still affected by my vague memories of what I felt
>> while reasoning about it two years ago, that is not being convinced
>> that the attacks described in the paper were part of what Tails is
>> seriously trying to protect against (as in: if an attacker can do
>> that, then they possibly have other, and maybe easier ways to do it
>> even if we kill access to RFC1918 addresses). Unfortunately, I've let
>> it in the shape of very incomplete and not publishable notes back
>> then, never came back to it, and have been feeling bad about it ever
>> since. Yay.
>>
>> I've sent these notes to Jurre, who's recently volunteered to think
>> this through. I'd love to see this happen anyway, but after two years
>> of waiting for it, maybe we should stop blocking on it and move on.
>> (Yes, it can take me a looong time to change my mind. You've not seen
>> it all yet.)
>
> I've thought it true, but i've been lazy and not sending out my
> thoughts. Luckily, it seems that we had similar thoughts, yay.
>
> I'm not an UX person but I see the following solution(s) living next to
> each other if needed. Coming from a security point of view, I believe
> it's better to enable things than to disable things. Most of our users
> might not understand the risks associated to attacks described in vpwned
> and dma capable devices. We therefor, shouldn't make them vulnerable by
> default but rather by choice and document in a clear way what the risks
> associated to it are.
>
> I'd also rather not advocate for a way to enable through out a session,
> it's like having intercourse and deciding, gosh, we're ready to go but
> we're out of condoms, but whatever, just this one time.

I think you fail to explain why having the decision during the session
makes the situation worse, and I do not think your metaphor is
particularly appropriate (and by that I do not mean that I think it's
immoral :). Damn language ambiguities!): the safer options would be the
default, so it's like being born with a condom that may be temporarily
removed. Furthermore, if the decision can be made at Greeter time only,
that means that the condom suddenly loses the ability to be removed as
soon as sex has been initiated. This is pretty weird, and at least I
cannot relate to the metaphor any more, so I'm dropping it. :)

> The implications might be for a lifetime.

The same goes for rebooting and setting picking the less safe option
when the user needs that. I don't see why allowing post-session
decisions changes anything w.r.t. exposure (except "Con 1", see below).

I think there arguments both for and against allowing post-session
security decisions (and I'm trying to be a bit more general here):

* Pro 1: if people are frequently frustrated by some security decision,
they will train a tendency to always pick the less secure option without
thinking. Having to reboot to redo the decision is frustrating. Allowing
it to happen during the session removes that frustration, and may make
the user more happy to pick the default, more secure option.

* Pro 2: with post-session decisions, the insecure option can be enabled
temporarily, only when needed, reducing the duration of exposure. At
least it is much less frustrating compared to yet another reboot. (This
doesn't make sense in some cases, like compromised hardware with DMA
access, which presumably would run it's attack immediately.)

* Con 1: if the Live user account is compromised during the session, the
attacker can make these decisions, potentially deepening the compromise
further.

* Con 2: at least some things are much harder to implement in such a
dynamic way (allowing/disallowing LAN ports is easy, though).

I'm sure there are more pros and cons, and I think we need to identify
these and weigh them against each other. As for the feature in question,
I think "Pro 1" and "Pro 2" are individually stronger than "Con 1", and
"Con 2" doesn't even apply.

> 1) When I boot Tails, i'm presented with an option to allow local
> traffic or not.
> 2) When I boot Tails, i'm presented with an option to allow certain
> local traffic like SSH and printing and the rest not.

Are these two distinct options? If so, what's the difference?

> 3) When I boot Tails, i'm presented with an option to be able to login
> to a captive portal, only this IP is whitelisted on the firewall rules
> and the rest is blocked.

Luckily, this is not needed. Captive portals are dealt with via the
Unsafe Browser, which still should have unrestricted access to the
network. Or am I missing some point why the Unsafe Browser should also
be affected by the LAN access blocking?

> I think my aim with providing these options is that, when you boot a
> computer, you often know what you're going to do with it or what you
> want access to or not. The same would go for allowing devices which are
> DMA capable like firewire, thunderbolt, pcmcia and others.

I agree with sajolida here: the requirements for a session can
drastically change. And reboots are frustrating...

> I guess that, the longer you use Tails, say a couple of hours, the more
> likely it *could* become you might be targeted by an adversary. If you
> would then half way allow access to a local network, who knows what
> might happen to the user or how more likely it could become that vpnwed

If the user enabled local network access halfway through, presumably
s/he needed it, so if we don't allow that to be changed during the
session, s/he would have rebooted, so everything is split over two
sessions. Could you elaborate why the duration of a single session is
any different than two consecutive sessions of in total equal duration,
and with equal duration of vpwn exposure?

While I can think of a number of things that change with new sessions,
like Tor entry guards, new Tor circuits for long-lived connections, new
spoofed MAC addresses, etc. all seem fairly insignificant, and they're
going both in favour and against your claim. Furthermore, I think
"be[ing] targeted" in general is the results of an adversary looking at
the end-points, and then nothing session-specific matters (well MAC
spoofing does for a LAN-level adversary; more sessions => more spoofed
MAC addresses => more suspicion raised).

Perhaps I am misunderstanding what you mean with "be targeted"?

Cheers!