intrigeri:[...]
I'll see to the rest of your reply later.
>>> Confusing message (actual behavior looks good, though):
>
>> Confirmed. Fixed. Changed to 'echo "uwt: localhost detected. Not
>> using torsocks."' and open for suggestions. I change it to
>> anything you suggest.
>
> "not using torsocks" vs. "exec torsocks ..." is still
> self-contradicting and confusing. Sorry if I was not clear from the
> beginning.
>
>>> (and probably fragile) parsing of wrapped command -- I find
>>> this to be a bit scary, as it silently assumes every occurrence
>>> of these strings in a wrapped command line means that the user
>>> wants to connect to localhost, which might not be the case:
>>>
>>> case "$*" in *127.0.0.1*) *localhost*)
>
>> Confirmed. No idea how this could be done better.
>
>> A -l for localhost option wouldn't make sense as uwt's main
>> purpose is to be used by wrappers. The magic "add stream
>> isolation for non socks aware applications with uwt hack while
>> not breaking localhost connections and while the user does not
>> have to care about" does not work so well. Open for suggestions.
>
> If you're happy to see semi-random commands (try to?) connect to
> the Internet directly, that is without going through Tor, then I
> suggest configuring torsocks to accept connections to localhost,
> and not try to guess (by fuzzy parsing command-line) if it should
> go through Tor or not. Depends on your threat model and system-wide
> design, mostly, and I admit I don't know the AOS' one enough to say
> anything about it.
>
> However, even if the current state of uwt fits AOS, I have to say I
> find it a bit scary to suggest [0] random users to use uwt in the
> current state of things: reading that page, they might think uwt
> will torify every command they wrap that connects to the Internet,
> and not randomly let it go through in the clear if it happens to
> contain this or that hardcoded string. Sorry if I missed something
> here.
>
> [0] https://trac.torproject.org/projects/tor/wiki/doc/torsocks#uwt
Ok, thanks very much! This was a serious issue. Now it fails for
non-aos users, so they stay safe. For aos users it's safe, nothing can
leak so or so. Worst thing that can happen is, that it runs without
stream isolation through Tor's TransPort.
For a real fix.... I don't think we can create a magic wrapper for
- - apt-get
- - wget
- - ssh
- - everything else, all in one
(Wrapper defined as: user just types apt-get and it runs through it's
own SocksPort.)
The magic wrapper:
- - stream isolates without the user being aware of it
- - the same wrapper also works for things like ssh 127.0.0.1.
Forcing through a SocksPort per applications will work by using
wrappers, but localhost connections on purpose will always remain an
issue. Using /usr/bin/git directly instant of git (uwt wrapper) will
be required for tests like "wget 127.0.0.1", i.e. "/usr/bin/wget
127.0.0.1".
