Because the directories are just used by the program anyway, so maybe not troubling to allow all that directories
1 Like
Also, /etc/onion-grater.d/30_autogenerated.yml needs to be removed by some script to avoid leaving that extraneous file
1 Like
Slow migration or even no migration. Maybe we’ll do the migration in the release-upgrade script to Whonix 17
Yes. Seems easiest. And easiest to revert should something unexpected happen and make this impossible.
merger (just in case it gets copy/pasted from here to git)
I guess that directory doesn’t hurt and makes the script easier to upstream.
That should be quite easy to do in the postinst script at the end when all of this has been implemented.
1 Like
This is what I am currently using to set different hosts and deprecate onion-grater-merger.
1 Like
In my view, this could be deleted, Dev/Control Port Filter Proxy/tor-controlport-filter/config - Whonix
important information already ported to dev page.
1 Like
Maybe no longer needed in context of onion-grater but I’d like to migrate the .d config explanations on some other page (more generic, unrelated to onion-grater).
1 Like
This pr is not good enough in terms or merging profiles.
Multiple dirs is working fine.
Multiple matches is not, it is more difficult than what I expected.
Sorting files in lexical order does not make sense because onion-grater stops at the first, even it make in reverse, the first match could not be enough for all cases.
If for example the a file containing hosts: '*' is matched, every host will only use that file, and no other even if it contains hosts: '*' in the other files.
The same apply even if hosts are specified such as hosts: '10.137.0.15' and the host match, it will not use any other file even if the host could match, it stops at the first file.
Unfortunately this is not done already on the onion-grater side because it was not written with that in mind.
What could be better done is transforming onion-grater-merger to separate files per hosts.
Lets take for example these files:
- a.yml - hosts: ‘10.10.10.10’
- b.yml - hosts: ‘*’
- c.yml - hosts ‘10.10.5.5’, ‘10.10.10.10’
The file b needs to be merged to all profiles.
The file a needs to be merged to the c profile
The file c needs to receive all profiles that either have all hosts or the matching hosts.
But this is just one aspect, the hosts, Tails uses apparmor-profiles and users, which lead to all sort of combinations of the qualifiers apparmor-profiles, users, hosts.
This means that there need to be a good way to merge in memory per the qualifiers, which gets more difficult with more qualifiers.
Lets take a bigger example know.
- a.yml
- apparmor-profiles:
- ‘/usr/bin/onionshare’
- ‘/usr/bin/onionshare-gui’
- users:
- ‘amnesia’
- ‘user’
- hosts:
- ‘10.10.10.10’
- ‘10.10.5.5’
- apparmor-profiles:
The three qualifiers are lists, they can hold multiple values. And this is only one profile, if you have to merge them in a way that it always results well.
From my tests, this was accepted by onion-grater:
- apparmor-profiles:
- '/usr/bin/onionshare'
users:
- 'amnesia'
hosts:
- '*'
it matched only the hosts.
From code comments
A filter is matched if for each of the relevant qualifiers at least one of the elements match the client. For local (loopback) clients the following qualifiers are relevant:
Upon tests:
Matchers: [('hosts', '10.137.0.44')]
Matched_filter: {'exe-paths': ['/usr/bin/onionshare'], 'users': ['amnesia'], 'hosts': ['*'], .........
So any qualifier matching, onion-grater will happily accept that. You won’t harden the profile by setting all three.
Profiles that accept every host should be merged with profiles accepting any host.
Profiles that have the same host, should be merged together.
On the other hand, by not specifying a qualifier, it will never match by that qualifier.
Match prefix is outdated for the merger, better to remove it.
And change exe-paths for apparmor profile.
1 Like
Broken links across the wiki because of wide search and replace.
In Whonix ™, there is only limited access to Tor’s control port (see [[Dev/onion-grater
|Control Port Filter Proxy]] for more information).
1 Like
Fixed.
Remember to separate the profiles per application, newnym is for TBB, bootstrap-phase for sdwdate etc, much better to understand which application needs what.
1 Like
Branch I am using GitHub - nyxnor/onion-grater at enhance
- allow to match multiple profiles and merge them together per matcher basis
- allow to set restrict-stream-events for remote hosts
- allow alternative directories to be parsed
after review, I will pr upstream.
1 Like
Note to self: I still need to look into this.
1 Like
Hi.
1 Like
About merge:
This is rather complex. And there’s low user demand for it. Various levels:
- Usability challenges of even understanding what Whonix is due to it’s unique dual-VM design, getting it installed at al. Few users.
- The usual Linux usability issues. Even less users.
- Usability issues of using applications that require onion-grater. Even less users.
- Users that want more fine-grained onion-grater control.
Hence, it’s a very detail and that’s not really something I want to spend a lot time on. The issue is also that these changes can probably not be upstreamed.
Debugging user reports of onion-grater issues is time intensive and painful already. By making onion-grater more complex, this adds only to it.
So what could be done? “A + B”
A) Keep the “normal” onion-grater as currently is - /usr/lib/onion-grater-merger remains unchanged.
B) Add the forked version that you invented as a separate script - add a new script such as /usr/lib/onion-grater-merger-somename. Not ideal to have code duplication but at least no regression and easy beta testing, easily revertible.
What could be “somename”? /usr/lib/onion-grater-merger-granular? Something better?
Then in the wiki users who wish to use the more granular way to use onion-grater / beta test can opt-in for it. (Using a wiki tab controller or something.)
Thoughts?
review and PR upstream:
Didn’t test. Best not to wait for me to unlock your progress. Generally looks good but it would require lots of testing to make sure there’s no regressions.
(Just make sure any PR to upstream does not include textual string “Whonix”.)
Even though this decreases the chance of people using it in the beginning, I believe it is worth it as it changes the behaviour and therefore the output.
1 Like
A change that could be implemented directly to onion-grater-merger is restrict-stream-events to work for remote hosts (filters streams per client/host).
Unfortunately I did a bad commit practice and used 1 commit for many changes… enhance onion-grater · nyxnor/onion-grater@d67b76f · GitHub (lines 355-356 and 364-367).
1 Like