Workstation hardcoded IP changes

Support
1

During an upgrade, I noticed a couple of changes in a whonix configuration files that include hardcoded IPs. Since I sometimes run more than one workstation at a time (VirtualBox), I have configured the second workstation to have another IP as explained in the wiki.

Now this upgrade asks me whether to keep my changes or to accept yours. I chose to keep my changes (selected “N” in both times I was asked) but I am not sure if this is OK, since I recall only setting the IP in one file and your changes now handle two files. Please advise - should I accept the changes and then reconfigure the IP as I did before or is ignoring your changes is fine?

1 Like
2

See: Ordinary Configuration Files

3

Thanks.
A somehwat related question: in the onion-grater’s wiki, it is mentioned that we can set the hosts directive to whitelist a specific workstation by its LAN IP.

Does this mean the IP that appears in /etc/network/interfaces.d/30_non-qubes-whonix after 'address"?

So for example, if this IP is 10.152.152.12, is it correct the setting in the .yml file should be:

hosts:
- ‘10.152.152.12’

If all that is correct, then the final question is - since onion-grater-add does all the work of adding profiles, which file/s should be edited to reflect the changes above?

4

That’s developer documentation.

For users, that’s unsupported.

5

How is that not for users?

I want to test CWTCH on Whonix, as you mentioned two weeks ago, “Testers wanted!”.

To do that I need to add the corresponding onion-grater profile. And I want to do it in a more secure way, so my test of CWTCH will be on a separate workstation. To make sure onion-grater indeed only whitelists tor commands from that workstation, changing the hosts directive is required.

The question is specific and is based on many hours of reading and digging into this subject. I will appreciate an answer. Of course, I will be happy to detail my experience of testing CWTCH for the benefit of others.

6

Ok. I did the following in the gateway:

cd /usr/share/doc/onion-grater-merger/examples
sudo cp 40_cwtch.yml 40_cwtch_1.yml
sudo nano 40_cwtch_1.yml

Added the Workstation’s IP instead of * in the hosts directive, saved the file, then:

sudo onion-grater-add 40_cwtch_1

Then verified it was added using

sudo onion-grater-list --used (sudo is probably redundant here)

And followed the instructions in the wiki regarding the workstation.

Sounds good?

Next steps:

  • Will test cwtch with this setting
  • If this works, I will change the hosts IP directive in my yml file to something else, to see onion-grater’s effect in blocking the request.
7

It can be tested as documented. Users should not navigate to Dev/onion-grater wiki page except for the purpose of curiosity, learning.

The wiki page is whonix.org/wiki/Dev/onion-grater. Dev means developer.

The mininav title is:

onion-grater (Developer)

The introduction text is;

onion-grater, a Tor Control Port Filter Proxy - filtering dangerous Tor Control Port commands - Design Documentation

Maybe design is unclear and should be replaced by developer.

This feature is unsupported due to the technical complexities of developing this feature. (onion-grater-merger versus onion-grater.)

Developer documentation isn’t as frequently updated as user documentation. Developer documentation can be hard to understand, lack context, have a “lost at hello” effect. Little effort is made to make it laymen friendly.

There’s only 1 “real” onion-grater configuration file:
/etc/onion-grater.d/30_autogenerated.yml

And it has only 1 hosts: directive. It’s auto generated based on snippets in /etc/onion-grater-merger.d. onion-grater does not have multiple hosts: support.

There is no feature “this hosts for that VM, another hosts for another VM”. There is only 1 global hosts for all incoming connections. onion-grater has been originally developed by Tails, not Whonix. It primarily serves the threat model of Tails. To keep the delta low, this feature hasn’t been implemented due to maintainability concerns.

Also:

Tor’s control protocol will be completely re-designed in Arti. Therefore there’s not the time now to make big changes in onion-grater.

What you’re asking for is not even something developers themselves are using.

And even if this feature did exist, it could be circumvented until connections between Whonix-Gateway and Whonix-Workstation are authenticated in Non-Qubes-Whonix. More information:

8

When I need to make changes, especially in the Gateway, I want to understand how things are working, whether the docs are for developers or users. I just found one onion-grater page, with specific instructions how to improve security. I was not lost at hello, I read and understood every word. If the following -

We can use the hosts directive, but the Whonix-Gateway doesn’t know which of your Multiple Whonix-Workstation requires the whitelist.

Because of this, we default to:

hosts:
- ‘*’

You can optionally change that directive to allow only the IP of your chosen Whonix-Workstation, therefore you can choose per host the rules you want to be whitelisted.

can’t actually be used, is obsolete, is wishful thinking, or it belongs to Whonix from a parallel universe, well that is at least an answer I can work with.

Since you have determined I am not a developer, let’s move to layman’s questions now:

Can various onion-grater profiles be used in parallel? For example, the files for Bisq and Bitcoin Core and cwch? any risks of conflicts between them? was such a scenario tested?

9

It’s due to the context. The text is about onion-grater. But Whonix doesn’t use onion-grater directly. It uses onion-grater-merger to create 1 onion-grater configuration file.

Maybe if disabling onion-grater-merger and using onion-grater directly. onion-grater might support multiple configuration snippets in /etc/onion-grater.d folder that each use a different hosts directive.

But since I haven’t tested this, the effort and complexity to document this, all the support requests asking about this (debugging why X does not work vs Y to figure out some usage error), it’s undocumented. In the process, bugs might be discovered. There’s no dedicated contributor supporting onion-grater either, and this might require multiple hours up potentially multiple weeks of work.

“Usually” they can. In theory, one profile might break another. In practice, there haven’t been reports about one profile breaking another.

The “basic”, default profile /etc/onion-grater-merger.d/30_whonix-default.yml is combined with opt-in profile(s) during development and during usage by users. There are no tests for all sorts of combinations.

Generally - at time of writing - unspecific to onion-grater - there’s no automated tests except systemcheck (which needs to be manually started). (Automated Tests)

The risk is broken connectivity by applications using Tor control protocol. (Those using onion-grater.)

1 Like
10

No, this isn’t easy. As per quote How onion-grater parses files:

How onion-grater parses files

Parsing stops at the first match. This means that it is not possible to override files by using a higher-precedence name such as 50_user.yml over 30_whonix-default.yml. onion-grater sorts the files in reverse lexical order, so if 50_user.yml matches, it will stop there; otherwise, it continues to 30_whonix-default.yml.

So each onion-grater configuration file would need to be “complete” or the same in other words, “fully merged”.

For instance, if only using 40_onionshare.yml standalone directly in /etc/onion-grater.d with the hosts directive, it might work, or it might be broken due to missing whitelisted Tor control protocol commands from 30_whonix-default.yml.

Or even if 40_onionshare.yml works as is standalone with the hosts directive, it would likely break functionality provided by 30_whonix-default.yml. (Tor Browser new identity feature, systemcheck and sdwdate.)

It might be fixable but creating a “fully merged” profile is non-trivial. Hence this is for developers only and unsupported for users.

11

That’s a pity. But even if we managed to limit the whitelisting to a specific workstation, still any application in that workstation could issue the whitelisted commands. The name of the onion-grater profiles suggests (so it seemed to me initially) that it might give the permissions to the named specific app only, but in fact the profile name only tells us “this app requires these commands”. It doesn’t tell us, “we allow these commands only to be ran by this app”.

Ideally, any app in the workstation should be expressely whitelisted by the user, after installation, perhaps with 2 permission levels (with / without Tor commands). I’d even print the whitelisted apps on startup to make sure nothing snack in there. Even better, we would have keys installed in both ends so the gateway could verify whitelisting or something similar.

And - how safe are the whitelisted Tor commands anyway? if they are, why do we even need onion-grater? allow them by default. If they aren’t, then allowing them in this way, especially when the origin of the commands isn’t restricted, seems like giving too much power to any app that sends info through the gateway.

Back to whitelisting a specific Workstation - I assume it’s still possible to do that with multiple Gateways. So that workstation would connect to a gateway that has the onion-grater profiles used. I guess that’s better than nothing, what I don’t like is too many changes with VM options, especially network settings, that can lead to mistakes.

12

Correct.

Ideally, yes.

This is answered in chapter onion-grater Warning. See footnote for security considerations.

Possible, and recommend as per above wiki chapter.

13

I read it. Pretty vague and no specifics. When discussing tor commands, it just mentions GETINFO address is terrible - that’s clear enough, but there is no discussion regarding potential dangers in the commands that do get whitelisted in the onion-grater profiles.

The forth point in the footnote you mentioned (in a page for users) links to the onion-grater page (the one for developers). Is that an escalation of reading privileges through footnotes backdoor? :innocent: I am not a Whonix developer but I found the courage to read that too.

Tor’s control port, in the context of Whonix, has dangerous features. The answer to the Tor control command GETINFO address will reveal the real external IP of the Tor client. Other dangerous commands include SETCONF, LOADCONF, GETCONF, and GETINFO ns/id/<relay-fingerprint>.

Now that’s better. But not enough. I hoped to see a discussion regarding the allowed Tor commands. Not only those that aren’t allowed. Do we have any references as to security issues, or lack of, with the whitelisted Tor Commands?

14

The primary concern and important link to follow is:

Onion Services Security

1 Like
15

The very general reply for users is: If you relax restrictions (such as onion-grater), you’re expanding the attack surface.

Written just now:
Tor Control Protocol Commands Considerations

Does that answer your question?

16

Makes sense for a very general answer, but this isn’t clear enough when we want to evaluate the specific risk per app.

Whonix uses onion-grater by default (with /etc/onion-grater-merger.d/30_whonix-default.yml). So if this whitelisting is considered safe enough, what exactly makes the other profiles potentially less secure?

The most dangerous known command not whitelisted by default:

add_onion: See Onion Services Security.
    But used by most onion-grater profiles. In that case, the documentation will show onion-grater warning.

Now this is helpful. I will go through the information in Onion Services Security. Obviously I got more reading to do to understand Tor better.

17

Yes.

Primarily add_onion.

A second example was already documented.

For others, you need to read the profiles and look up the commands description in the Tor control protocol.

1 Like