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
