[tor-bugs] #3313 [Tor Client]: Security enhancement against malware for Tor

[Tor Bug Tracker & Wiki]

#3313: Security enhancement against malware for Tor
----------------------------+-----------------------------------------------
    Reporter:  ioerror      |       Owner:  ioerror         
        Type:  enhancement  |      Status:  reopened        
    Priority:  major        |   Milestone:  Tor: unspecified
   Component:  Tor Client   |     Version:                  
  Resolution:               |    Keywords:                  
      Parent:               |      Points:                  
Actualpoints:               |  
----------------------------+-----------------------------------------------

Comment(by ioerror):

 Replying to [comment:19 atagar]:
 > Little update from what ioerror and I have been discussing on irc. We
 have a partial workaround that limits the impact on arm - since we still
 have netstat results I can filter on the uid of the tor owner rather than
 the pid. This has the obvious disadvantage that it may be overly inclusive
 if tor isn't run under a dedicated user, but should be fine for the deb
 use case.

 Right - so in essence we get all the security features we want, we look at
 /proc/net/tcp for a reasonable guess and on Debian systems or any systems
 with a dedicated uid, we're pretty much certain.

 >
 > I'm not sure how this will work for BSD platforms because neither
 netstat nor proc contents are available there. That said, I'm not sure if
 this feature effects lsof/sockstat/procstat at all on that platform so it
 may not be an issue.
 >

 Using these tools as an API is not stable. What if the OS had changed
 this? That is - what if the Ubuntu kernel change had caused this? As it
 stands, arm won't work on grsec enabled kernels that have similar
 restrictions as far as I can tell.


 > -Damian
 >
 > PS. Sorry for flagging this as a blocker. I didn't realize that we
 reserved that status for critical security issues. At work it just means
 that it needs someone to look at it before final release.

 We're pretty far from a final release and it's good to highlight the
 issues.

 The good news is that what we have lost by adding this feature is
 literally this and this alone:

 {{{
 01:16 < atagar> if we're looking for the subset then we can simply look at
 the return values for the connection utils - that's all I care about :)
 01:17 < atagar> so that would just be the current ip/port on the local and
 foreign end
 01:17 < atagar> everything outside of that I discard
 01:17 < atagar> getting this from the control socket has the obvious
 advantage that we can get extra information that I currently need to infer
 01:18 < atagar> like which connections are exit/client and hence private
 01:18 < atagar> or which are directory/hidden service/client related
 01:19 < atagar> here's the proposal we came up with:
 https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/172-circ-
 getinfo-option.txt
 01:20 < atagar> hm, forgot we had dropped connection info from that
 proposal
 }}}

 So - the main change is the connections that are ESTABLISHED or in a phase
 of connecting is that only information that is lost. I think that this is
 something that we could add to the heartbeat - arm could then get the
 information directly from Tor and it would be portable. We already have an
 internal state for those connections that includes important metadata
 anyway, right?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3313#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online