Re: [Tails-dev] Please test feature/unsafe-browser

Delete this message

Reply to this message
Autor: intrigeri
Data:  
A: The Tails public development discussion list
Assumpte: Re: [Tails-dev] Please test feature/unsafe-browser
hi,

anonym wrote (12 Apr 2012 18:32:52 GMT) :
> 04/04/2012 06:24 PM, intrigeri:
>> another concern I have with the current state of
>> feature/unsafe-browser is that the clearnet user is allowed to connect
>> to Tor, Polipo, pdnsd and ttdnsd, which may make possible some classes
>> of new deanonymization attacks against Tails users.


> Good point. It should be enough to add something like "! -o lo" to
> the clearnet user's firewall exception rule.


Agreed.

Would you please update todo/add_support_for_free_wifi_hotspots to
match the current status of the implementation, and the remaining
problems that are still to be fixed?

>> I guess it would be relatively easy to implement stricter permissions,
>> similar to Liberté's policy on the loopback network interface (see
>> src/usr/local/sbin/fw-reload in their source tree).


> Yeah, this is a good idea in general. While we're at it, perhaps we
> should take a more whitelist and principle of least privilege oriented
> approach? I'm thinking something like:
> [...]
> I don't know. Maybe all this just adds complexity to our setup with
> little (or just imagined?) added security compared to a blacklist
> approach? OTOH it forces us to be really conscious about new loopback
> services and users that are added, which is good in itself.


> Thoughts? I'll create a todo/firewall_lockdown if we like this idea.


I like it, please go ahead with the ticket creation.

> (At the same time I think we should move to using a shell script
> which loades the rules... it's handy to have variables at
> one's disposal.)


I agree we should move to a higher level, but I'd suggest we use ferm
instead (apt-cache show ferm). This, in itself, would be worth
a ticket.

>> IIRC it was also suggested to simply shutdown Tor altogether while the
>> unsafe-browser is running


> That might be good for other reasons. In fact, as long as we don't have
> a 100% accurate is_tor_working() function this seems like the safest
> approach. There may be some thinking necessary for making all this
> integrated with our time syncing.


Ah, now I remember why we don't want this:
many captive portals need you to re-authenticate on a regular basis,
meaning you practically have to let the unsafe browser running.

> Hmm, perhaps it'd be a good idea to notify the user when we
> wait_for_tor_consensus() but it fails during time syncing, telling them
> that *perhaps* they're behind a captive portal and should use the Unsafe
> Browser to register/login?


ACK -- as a new feature, this would need a new ticket.

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc