04/13/2012 10:18 AM, intrigeri: > 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.
I also realized that the rule accepting all loopback connections need to exclude the clearnet user. Done in commit b98c377. > 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? Done in commit b1e5c92. >>> 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. Created in commit d250257. >> (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. Cool. Created in commit 4053070. >>> 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. Ah... right. >> 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. Since there's already a section for future stuff in the existing ticked I put it there (also commit b1e5c92). Cheers!
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
