[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Should strict stream isolation by a requirement in Whonix's Default Appliation Policy?


#1

I’ve been quite strict about this. No pre-installation of software which cannot be configured to use a Tor SocksPort. I.e. which pollutes Tor’s TransPort, i.e. that uses system default networking without using a dedicated Tor SocksPort. (That goes for graphical / user applications.) So the DNS for gajim being resolved by Tor’s DnsPort would make gajim unfit for pre-installation in Whonix.

Does the description of the current policy make sense?

I am not sure I have been too strict about this. This for example is one obstacle of installing electrum by default. (ticket) (It’s hard to pre-configure electrum so it would be stream isolated by default.)

When throwing this requirement out of the window, we could end up with users using both gajim and electrum at the same time, all going through the same Tor circuit.

Related:

//cc @marmarek


#2

Its a sane policy and makes sense. Its a good defense in depth in case a user launches different identity activities in the same VM by mistake.


#3

@JasonJAyalaP in https://phabricator.whonix.org/T694

I’m thinking that “stream isolation as a requirement” keeps our hands clean in the event of a highly sophisticated attack, while letting our users fumble in in the dark (such as installing pidgin, or installing gajim but not configuring it) or giving up.


#4

Resolution: strict stream isolation removed from Whonix Default Application Policy.


#5

For clarification, my understanding is that some of the pre-installed programs in Whonix-Workstation will share the use of Tor transport. And since IsolateDestPort and IsolateDestAddr can’t be set for Tor transport, this policy will cause programs that can’t be assigned a socksport sharing of same circuit when they are running at the same time. Is this correct?

If so, can we at least somehow document on what those programs are? And maybe even open a brief ticket for each of them so that we can assign them a socksport whenever it’s possible?


I noticed /usr/share/tor/tor-service-defaults-torrc provided the rationale that the reason why IsolateDestPort and IsolateDestAddr cann’t be enabled is because of the file sharing program, is there any other common use case we can come up with that prevents us from enabling them? If not, maybe I can think about how to deal with it.

###############################
## Workstation Trans/Dns-Port #
###############################
## (comment mirrored from /usr/bin/whonix_firewall)
## Transparent Proxy Port for Workstation
## TRANS_PORT_WORKSTATION="9040"
##+# #OptionalFeatureNr.5# Best possible protection against Identity correlation through circuit sharing. ^5^
##
## TransPort is not used for anything preinstalled by default.
## Only as a catch all for user installed applications,
## which is documented.
##
## IsolateDestAddr should not be activated by default,
## if people install filesharing software it would be a nightmare if all connections to the massive amount
## of destination IP's would go through separate circuits.
##
## For the same reason IsolateDestPort should not be activated by default, since BitTorrent (in some cases)
## uses random ports.
TransPort 10.137.5.1:9040

#6

Stream Isolation is one of the most important feature of Whonix. A lot of people try to use their own workstation or even their own gateway because they didn’t know what they may lose.

A program that help/assist/advice users to assign proper socksport may be very helpful to take the full advantage of Whonix. If user can assign a socketport to the file sharing program or other self-installed program, they will be less vulnerable to identity-correlation attack.


However, I know that a lot of programs do not support proxy configuration and some of the file sharing programs are infamous for disobeying the proxy configuration. Therefore, it would be nice if we can somehow force a program to use a certain proxy.

Under windows, there is an application called wincap that can do the job, maybe we can find a linux alternative?


#7

@iry Sometime back I outlined a standardized way we can use to safely force applications that don’t support stream isolation to work safely under Tor: Managing programs without Tor DNS Support

How difficult would you find such a project?

PS. Since firejail was recently re-mentioned could it work here since it could give each sandboxed application its own virtualized namespace?


#8

@Patrick Meanwhile an alternative would be to enable something like IsolateClientProtocol so traffic going through TransPort does not carry DNS traffic and so on.

Looking at the DNSPort option I see it also supports an Isolate parameter similar to IsolateAddr but in this case we would be enabling just for DNS traffic if combined with the option above.

What do you think?


#9

iry:

For clarification, my understanding is that some of the pre-installed programs in Whonix-Workstation will share the use of Tor transport. And since IsolateDestPort and IsolateDestAddr can’t be set for Tor transport, this policy will cause programs that can’t be assigned a socksport sharing of same circuit when they are running at the same time. Is this correct?

Correct.

If so, can we at least somehow document on what those programs are?

Sure, lets add them here:

https://www.whonix.org/wiki/Stream_Isolation#none

And maybe even open a brief ticket for each of them so that we can assign them a socksport whenever it’s possible?

Good idea.


I noticed /usr/share/tor/tor-service-defaults-torrc provided the rationale that the reason why IsolateDestPort and IsolateDestAddr cann’t be enabled is because of the file sharing program, is there any other common use case we can come up with that prevents us from enabling them?

Any custom installed application by the user that behaves in similar
ways. Cannot be foreseen.

If not, maybe I can think about how to deal with it.

That would be interesting.

Managing programs without Tor Socks / DNS Support
https://phabricator.whonix.org/T772

I described here a generic way that should allow stream isolating any
application even better than our current torsocks based implementation:


#10

https://www.torproject.org/docs/tor-manual-dev.html.en

IsolateClientProtocol

Don’t share circuits with streams using a different protocol. (SOCKS 4, SOCKS 5, TransPort connections, NATDPort connections, and DNSPort requests are all considered to be different protocols.)

The manual no longer mentions what setting is default and which not. Previously it did. I am pretty sure, last time it was saying IsolateClientProtocol is the default already. In case IsolateClientProtocol isn’t the default, we should make a torproject ticket and request it being made the default.

In that case we should also request from Tor Project to make these the default for DnsPort to see their rationale should they refuse.


#11

Asked TPO: https://lists.torproject.org/pipermail/tor-dev/2018-June/013235.html


#12

Good question, good answer received already! Could you rehash his answer as comments addition to tor-service-defaults-torrc please?

https://github.com/Whonix/anon-gw-anonymizer-config/blob/master/usr/share/tor/tor-service-defaults-torrc.anondist#L152

And could you follow up please why IsolateClientProtocol isn’t enabled by default?


#13

Teor already covers this, please see second point in post.

Summary:

  • All the isolation flags that aren’t specified as defaults are not defaults.

  • Different socksports/transports are isolated from each other by default, IsolateClientProtocol would disable this.

  • IsolateDest + DNSPort negatively impacts performance, network resources and privacy therefore not recommended.

  • SOCKSPort/HTTPTunnelPort are recommended alternatives, sending out DNS requests with each connection’s outgoing data respectively.

I will try and format that in an appropiate way for committing in comments.


#14