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
>
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
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
> 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
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
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
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
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.
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*
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
10 matches
Mail list logo