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 _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
