Re: [Tails-dev] vpwned

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Old-Topics: [Tails-dev] vpwned
New-Topics: Re: [Tails-dev] vpwned, Re: [Tails-dev] vpwned + greeter
Subject: Re: [Tails-dev] vpwned
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.)

Regardless of whether the specific attacks described in that paper
apply, I see that we've left this open for too long, especially since
we're apparently not able to find time to check how our design resists
to published attacks.

I see #7976 is on the agenda for the next monthly meeting, and if time
permits we could perhaps extend this discussion to the broader topic.

> This change may require some UI changes for enabling access to the
> local network. I suggest that such access is disabled by default.


Once we reach a consensus about the general goal, someone (possibly
you!) should get in touch with our UX team (tails-ux@???
mailing-list) regarding how best this should be done.

Maybe the first step would be to identify what kind of usecases we
want to support on the LAN: it might turn out that more focussed,
usecase oriented pieces of UI than an "allow all traffic to the local
network" boolean thing in the Greeter would be more appropriate.
See e.g. what was suggested on
https://labs.riseup.net/code/issues/5293#note-4 and
https://labs.riseup.net/code/issues/7976

It's likely that quite some more time can be needed until we have
a full-fledged UI that gives us all we want, and allows us to switch
to "forbid RFC1918 by default" without breaking too many existing
usecases. Our UX folks are already busy with the Greeter revamp (that,
incidentally, might be part of what we need here).

So, a first (baby) step that could allow us to start moving in the
right direction would be to unconditionally allow access to a specific
list of ports only.

So, let's start listing usecases. Mine are:

  * downloading from / uploading to a FTP server
  * printing a document on a network printer
  * going through whatever steps a captive portal asks me to;
    this generally involves DNS and HTTP


What else?

Cheers,
--
intrigeri