procmem@???:
> On 10/29/20 3:18 PM, anonym wrote:
>> procmem@???:
> On a related note, with restrict-stream-events set to true, I was still able to access all stream events when testing with netcat in the workstation VM. Initially it worked as intended and didn't pass this info, but during subsequent trials it would read everything Tor was doing.
Woah, so it would probably work inside Tails?! I am very much interested in reproducing and investigating this in that case. Please help me out with any info/instructions you have about this!
> Follow up: what is the best approach to capturing this section of the pattern
>
> $relayid~$relayid,$relayid~$relayid,$relayid~$relayid
>
> ?
>
> Just using (\S+) once or
>
> do I have to do \$(\S+)~\$(\S+),\$(\S+)~\$(\S+),\$(\S+)~\$(\S+)
>
> ?
I'd say, use the most accepting rule that doesn't break the functionality you want to keep since it is the more fail-safe approach, so if the first one works, it's better IMHO.
>>> * Is it even possible to sanitize responses as large and varied as stream-events output without having something leak thru or is it best to keep it blocked for peace of mind?
>>
>> Theoretically, I think yes, but any black-list approach is pretty much futile to get perfect unless you put unreasonable resources on maintaining it. So at best you it can be considered in a defense-in-depth approach, but not as a single defense, IMHO.
>>
>
> I think another problem is circuit info is multi-line and don't all start with 250+circuit-status=
>
> I'm guessing this prevents any use of a wildcard as an easy catch-all for the whole replies?
First, let's note that the rewrite rules operate on a per-line basis, which indeed puts some limitations of what is possible.
My understanding is that you want to rewrite the multiline response of e.g. `GETINFO circuit-status` from something like:
250+circuit-status=
16 BUILT …
18 EXTENDED …
…
.
250 OK
to an "empty" response:
250+circuit-status=
.
250 OK
Is this correct?
If so, yes, I think there is a problem. I believe the best we can do at the moment is to have a rule like:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
replacement: ''
i.e. that matches all the other lines of the response and replaces them with the empty sting... but that would result in a response with a bunch of empty lines in it:
250+circuit-status=
<empty line>
<empty line>
… one <empty line> for each circ
uit …
.
250 OK
which is think is invalid according to the control-spec. But it's worth testing, I guess! :)
But the better solution would be to extend onion-grater with something like the `suppress` option that exists for events, e.g.:
GETINFO:
- pattern: 'circuit-status'
response:
- pattern: '[0-9]+ (BUILT|EXTENDED|…) .*'
suppress: true
which would mean that any response line matching the pattern is completely dropped. I'm not completely sure, but it shouldn't be that hard to implement.
Is this what you would like, or am I way off? If the latter, please try to explain in more detail what it is you want to achieve, preferably with concrete examples of the Tor output you get and exactly how you want it transformed.
Cheers!
