anonym:
> Yay! Let's try to make this fork short-lived!
Yes! :)
> Note that Tails' version has changed quite a lot since you forked --
please try to keep your fork delta minimal (i.e. only do what *must* be
done)!
Our diff of the filter is quite mergable, I guess. In summary:
- filters = yaml.safe_load(fh.read())
- #!/usr/bin/python3 -u so python exceptions end up in journal
- config parser
- --listen-interface (which you already said you want to add)
(And the packaging stuff is not all that difficult?)
We have a ticket for merging Tails' version into Whonix's version so we
get your enhancement and so the diff looks simpler. [1]
> So, since all your filters match *everything*, you could actually
merge all the filters yourself into a single filter rule file, right? In
fact, the only non-sytlistic reason you want merging of multiple matched
rules is to allow Whonix users to add their own filters without
overwriting yours (which causes issues during Whonix upgrades), correct?
>
> If so, I think I have a simpler solution: we introduce a new top-level
key called `override` which takes a list of strings. If such a filter is
matched together with a filter whose name is listed in `override`, then
the `override`-filter is merged into the other one, and has priority
whenever there's any ambiguity. So with this, Whonix would ship a
single, nicely commented filter called 'whonix', and users that need to
modify it simply creates a filter with `override: ['whonix']`.
>
> The only drawback I can see is that Whonix cannot organize the filters
in separate files this way, but I think that is a small prize to pay for
such a simple solution to this problem (which I fear otherwise can make
it really hard to reason about filters when they grow in number). I
actually think Whonix having a single file is slightly advantageous
since you use the same match rules in every filter.
>
> Would this work for you?
No. (However, I am not sure I fully understood your proposal.
Technically at the moment all config file snippets are merged into the
same merged filter rule.)
Having the filters split in multiple files is very much desirable. We
want to ship a maximally restrictive config by default. And then allow
users to make it more permissive as required depending on their use case.
Just two different configs, one for maximum restrictive vs one for
custom maximum permissive is probably not right balance here.
(We match everything because of necessity - to keep the code complexity
manageable. Matching by IP would be a nice feature, so would be a
profile on the gateway that only matches `arm`.)
For example, adding onionshare is one of the safer applications one can
whitelist due to the limited range of listening ports it opens. ricochet
is more crazy, since all ports need to be allowed. (Something being
discussed with upstream so this may change for Debian buster.) Some
applications want to see the onion's private key [ricochet, so it can
restore it later], for others we can inject DiscardPK and redact it. I
think other applications will require access to further Tor internal
states. Ricochet uses STATUS_CLIENT, but fortunately also does not break
without it yet.
Having to use something like "override: ['whonix']" and somehow have a
hierarchy of files named that way, if they are splittable/stackable,
would of course not be an issue.
> Beyond that, I'll add your `--listen-interface` option, and I'll add a
`--filters-dir` option that can be used to override the default filters
dir, and that can be passed multiple times (so you'll pass
`--filters-dir /etc/tor-controlport-filter.d --filters-dir
/usr/local/etc/tor-controlport-filter.d/`).
That's great! (Please don't fail if the folder does not exist - logging
that only would be a lot better.)
Cheers,
Patrick
[1]
https://phabricator.whonix.org/T612
