anonym:
> https://tails.boum.org/news/report_2016_09/#index2h1
>
> and look at the documentation at the top of the script, and the filter
> rules we ship to get an idea of what it can do.
> As you can see, in Tails we use match-exe-paths and match-users a lot,
> but since you won't have access to these I guess you want something like
> match-hosts, so that the filter is picked based on the client's
> (non-localhost) address (= VM). Right?
The match-hosts works well for Whonix. Set to "*" for now.
>>>> - https://phabricator.whonix.org/T562
>>
>> This is about parsing add_onion and whitelisting sane commands rather
>> than letting through everything.
>
> For any command we allow a list of regexes for the arguments. If a
> command doesn't match any of them, it is filtered.
Sounds good!
>> add_onion is not a whitelist/not whitelist.
>
> I do not understand this sentence...
Originally we at Whonix thought we wanted "wildcard support". Meant,
matching just "add_onion *", i.e. letting everything through
that comes after "add_onion". As it turned out, that was insufficient.
For example, add_onion flag "nonanonymous" ought to be avoided.
Tails control port filter proxy seems to keep care of that.
>> Buggy applications or by user mistake, they could choose the add_onion
>> flag nonanonymous, which would be a disaster. We also don't know what
>> Tor control protocol upgrades are coming in the years to come. So I
>> strongly suggest a only letting through whitelisted syntaxes.
>
> ... but this I get and agree with. Currently we require ADD_ONION for
> onionshare to have args matching the regex 'NEW:BEST Port=80,176\d\d'.
Great!
>> Malicious applications could make the Tor HS listener bind on the wrong
>> interface. In Whonix-Gateway, maliciously listen on Whonix-Gateway.
>> Which could be fatal if we had also a real Tor ControlPort open there.
>> Does that make sense? I am not sure it applies to Tails, that depends on
>> your design and threat model, but it is however an interesting thought
>> that can inspire to finding more security issues with it.
>>
>> Also it may be worth making sure it can only bind to specified (and
>> configureable) local ports?
>
> Ack, this is an issue. In Tails there must be an explicit firewall rule
> allowing a user listening on some port, so I think we are covered.
Ok.
>> For connectivity, we need to remove 127.0.0.1 and replace it with
>> Whonix-Workstation IP. That is currently done with the following code
>> block that I was going to merge with T562.
>>
>> https://github.com/Whonix/control-port-filter-python/blob/6a131266a8dc8f98ff22a3b83fae9d43e38b3127/usr/sbin/cpfpd#L345-L375
>
> Got it. Our filter doesn't do this (as we do not have this need) but I
> feel a general solution could be to allow sed-like rewriting rules, e.g.
>
> ADD_ONION:
> - pattern: 'NEW:BEST Port=80,(176\d\d)'
> replacement: 'NEW:BEST Port=80,10.137.6.41:{0}'
>
> which would be easy to implement.
Yes, that would work for Whonix.
>>>> - https://phabricator.whonix.org/T564
>>
>> Protecting cpfpy from DDOS from client applications. Not sure that
>> matters for Tails?
>
> We do not do much specific here. What kind of DoS are you talking about
> here? Eating up all RAM or crashing the filter via oom kill? Preventing
> the filter from serving other clients? We admittedly do not do much here
> except that each client is dealt with in a separate thread, and that
> client requests are limited to 1024 bytes.
Yes, I meant crashing the filter or making the whole computer unusable
by flooding cpfpy with too much requests.
>> - Supports logging.
>
> I'm not sure what type of logging you are talking about here. Currently
> it uses print() (to stdout) and flush, which works well with the journal
> when run as a systemd service.Normally only filtered commands are
> logged, but there's also a --complain mode which logs all client
> requests, which is useful when writing rules for a new application.
Sounds fine!
>> - systemd support
>
> Not sure what this means. We have a .service file.
That's it.
>> - When request is 'getinfo net/listeners/socks' answer with a lie
>> '250-net/listeners/socks="127.0.0.1:9150"'.
>
> Nope. Why is this needed?
Rather minor: Not revealing all the listeners to all connected
workstations.
> I could even imagine yet another rule-type for solving these types of
> issues:
>
> GETINFO:
> - pattern: 'net/listeners/socks'
> respond: '250-net/listeners/socks="127.0.0.1:9150"'
Seems great!
