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

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!