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! _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
