Provide Privileged and Unprivileged control ports
(This may be a duplicate because I know this has been discussed before, but I couldn't find the original if it exists)
The control port has the potential ability to pass sensitive information (legacy/trac#3521 (moved), legacy/trac#5976 (moved), legacy/trac#1949 (moved)). There may be situations where one controller only needs the ability to query and receive a limited amount of information and another controller handles the sensitive information. These two processes should be able to connect/authenticate to different sockets and and thus prevent the first process from receiving sensitive information.
Alternatively, this same isolation can be achieved using the chosen authentication mechanism.
Whichever is better (or if both, or another, are chosen), the capabilities of the connection should also be configurable via torrc and control port. For example, whether a connection is allowed to SETCONF or only GETCONF and SETEVENTS, etc. A high level of granularity would be ideal.
Activity
Trac:
Keywords: N/A deleted, needs-proposal added
Description: (This may be a duplicateas I know this has been discussed before, but I couldn't find the original if it exists)The control port has the potential ability to pass sensitive information (legacy/trac#3521 (moved), legacy/trac#5976 (moved), legacy/trac#1949 (moved)). There may be situations where one controller only needs the ability to query and receive a limited amount of information and another controller handles the sensitive information. These two processes should be able to connect/authenticate to different sockets and and thus prevent the first process from receiving sensitive information.
Alternatively, this same isolation can be achieved using the chosen authentication mechanism.
Whichever is better (or if both, or another, are chosen), the capabilities of the connection should also be configurable via torrc and control port. For example, whether a connection is allowed to SETCONF or only GETCONF and SETEVENTS, etc. A high level of granularity would be ideal.
to
(This may be a duplicate because I know this has been discussed before, but I couldn't find the original if it exists)
The control port has the potential ability to pass sensitive information (legacy/trac#3521 (moved), legacy/trac#5976 (moved), legacy/trac#1949 (moved)). There may be situations where one controller only needs the ability to query and receive a limited amount of information and another controller handles the sensitive information. These two processes should be able to connect/authenticate to different sockets and and thus prevent the first process from receiving sensitive information.
Alternatively, this same isolation can be achieved using the chosen authentication mechanism.
Whichever is better (or if both, or another, are chosen), the capabilities of the connection should also be configurable via torrc and control port. For example, whether a connection is allowed to SETCONF or only GETCONF and SETEVENTS, etc. A high level of granularity would be ideal.
This is a good idea, but it's going to take serious design work and hard thought about a threat model. Is there any nontrivial functionality from the control port that is completely safe to expose to a totally hostile program? If the answer is "yes", or if we can identify a well-considered variation on "completely" and "hostile" that makes the answer "yes", this might be worth doing.
I suggest closing as duplicate of legacy/trac#8369 (moved).
(I also don't see a way to accomplish this goal in a workable manner. But keeping one ticket open about it, to attract the people who want it to happen, sounds fine to me.)
Trac:
Severity: N/A to Normal
Reviewer: N/A to N/A
Sponsor: N/A to N/Amoved from legacy/trac#11376 (moved)
added Feature label and removed 1 deleted label
added Needs Proposal label and removed 1 deleted label