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

On Mon, 10 Apr 2017 19:35:24 +0400 meejah 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 >

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

anonym writes: >> It allows "GETINFO onions/current", which can expose a list of every >> onion service locally hosted, even those not launched through >> onionshare. > I think this can be disallowed; in fact, when looking at the > onionshare and stem sources I don't see why

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

Nick Mathewson: > Hi! > > As you may know, the Tor control port assumes that if you can > authenticate to it, you are completely trusted with respect to the Tor > instance you have authenticated to. But there are a few programs and > tools that filter access to the Tor control port, in an

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

> Yes, that is necessary. I question, however, whether it is sufficient. Sufficient for what purpose? It *is* sufficient for the purpose of preventing Subgraph sandboxed applications from escaping it's sandbox via the Tor control port. Actually, one of the Subgraph guys figured this out and

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

Hi Nick. Just a quick note that something I've wanted from time to time is a 'make the control port read-only' option so only GETINFO, GETCONF, events, etc would work. Yes, these could be used to deanonymize a user, but it could provide assurance the controller doesn't tamper with tor. This has

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

On Mon, Apr 3, 2017 at 6:39 PM, dawuud wrote: > > > It's worth noting that controllers able to run SETCONF can ask the tor > process to execute arbitrary programs: > > man torrc | grep exec > > So if you want a controller to have any less privileges than the tor > daemon

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

It's worth noting that controllers able to run SETCONF can ask the tor process to execute arbitrary programs: man torrc | grep exec So if you want a controller to have any less privileges than the tor daemon does, you need a control port filter for SETCONF at the very least. Without a

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

For what it's worth, since there's a filter that's shipped and nominally supported "officially"... On Mon, 3 Apr 2017 14:41:19 -0400 Nick Mathewson wrote: > But I could be wrong! Maybe there are subsets that are safer than > others.

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

Nick Mathewson writes: > But I could be wrong! Maybe there are subsets that are safer than > others. So, I guess the "main" use-case for this stuff would be the current users of control-port filters (like Subgraph and Whonix; others?). It seems what these things *really*

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

Hi! As you may know, the Tor control port assumes that if you can authenticate to it, you are completely trusted with respect to the Tor instance you have authenticated to. But there are a few programs and tools that filter access to the Tor control port, in an attempt to provide more restricted