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! _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
