[tor-dev] Control-port filtering: can it have a reasonable threat model?

[Yawning Angel]

On Mon, 10 Apr 2017 19:35:24 +0400
meejah <meejah at meejah.ca> wrote:
> Obviously as per my other post I agree with fragmented / limited views
> given to "real" applications of the control-port. However, personally
> I don't see the point of implementing this in 'tor' itself -- existing
> control-port filters are "fairly" limited code, typically in "safer
> than C" languages anyway. So then you have the situation where
> there's a single trusted application (the filter) conencted to the Tor
> control-port.

I agree with this, because it's basically required to do certain
things, and for certain adversarial models.

> Ultimately, it would probably be best if there was "a" robust
> control-port filter that shipped as part of a Tor release. So if that
> means "must implement it in C inside Tor" I guess so be it.

I moderately disagree with this.  It's not clear to me if a one size
fit's all solution (that supports all "first class platforms" and use
cases) would be easy to develop initially, and it will take continuous
love and care to support everything that people want to do.

By "first class" platforms in this context (since it's more client
facing) I'll start off with "Whatever Tor Browser happens to be
packaged for" as a first pass narrow definition.

Even if this was shipped, I'm trying to keep the external dependencies
required for correct sandbox functionality to a minimum, and something
that's part of the bundle it downloads/auto updates doesn't feel great
to me.

> Maybe this would be a good target for "experiment with Rust" if
> anyone's excited about writing control-port code in Rust...?

I disagree with this, but since it'll never be used by the sandbox, my
disagreement shouldn't stop anyone.

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170410/737bd57b/attachment-0001.sig>