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.
> 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:
* We reject all loopback connections by default.
* For each service on loopback we create a group whose membership mean
that access is granted to the service through a firewall rule:
- fw-tor-socks => tcp 127.0.0.1:9050
- fw-tor-ctrl => tcp 127.0.0.1:9051
- fw-tor-dns => tcp 127.0.0.1:8853
- fw-dns => tcp/udp 127.0.0.1:53
- fw-ttdnsd => tcp/udp 127.0.0.2:53
- fw-proxy => tcp 127.0.0.1:8118
- fw-i2p => tcp 127.0.0.1:{4444,4445,6668,7657,7659,7660}
- fw-cups => tcp 127.0.0.1:631
- fw-monkeysphere => tcp 127.0.0.1:XXX (MSVA_PORT=XXX in environment)
- others?
* We add the following users to the following groups:
- amnesia: fw-tor-socks, fw-tor-ctrl, fw-dns, fw-proxy, fw-i2p,
fw-cups, fw-monkeysphere
- proxy (i.e. polipo): fw-tor-socks, fw-dns
- root (for APT): fw-dns, fw-proxy
- pdnsd: fw-ttdnsd, fw-tor-dns
- htp: fw-dns, fw-proxy
- nobody (see below): fw-tor-socks
- others?
ttdnsd is hardcoded to chuid to nobody but since nobody might be used
for other processes with other requirements (e.g. jake's other project
which we may consider using at some point, tlsdate, which has the same
hardcoded privelege drop) it'd be great if we could send a patch/request
to upstream ttdnsd for adding a "--chuid <username>" option. I don't
think any other process in Tails runs as the nobody user right now, so
there's no hurry.
Since some of the above groups will only be used by one user (only pdnsd
needs fw-ttdnsd, only amnesia needs fw-i2p and fw-tor-ctrl) those groups
could be skipped and the firewall rule could be made matching the user
instead. OTOH using the group management approach for everything may be
more consistent.
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.
(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.)
> 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.
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?
> which might be simpler than
> a iptables-based solution to this problem (independently from that,
> I think a stricter iptables policy would be a welcome hardening
> improvement anyway).
I agree with your parenthesis.
> (I can't find any summary of our previous thinking on this topic, so
> if we already dismissed it for good reasons, at least it should be
> made explicit in the design notes.)
AFAICR we've mostly discussed the GUI, and everything should be in
todo/add_support_for_free_wifi_hotspots.
Cheers!
