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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Dec 20 07:06:43 UTC 2011


#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:21 atagar]:
 > > 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.
 >
 > Yup. I'll probably check if the uid belongs to debian-tor and, if not,
 give a warning about possible bad data in the connection panel since
 custom setups are more likely to have non-dedicated users.
 >

 Why not exclude the data in that case?

 > Is there anything tor could check to see if the kernel already has
 ptrace protections built in and, if so, not do it ourselves? This would
 mean that on Ubuntu or other platforms with ptrace disabling built in arm
 would work normally (between that and our workaround I'd be happy to call
 this good).
 >

 I don't think that is a good idea. I do not believe there is a portable
 way to test for such a similar kernel feature across the platforms where
 we call ptrace.

 > > Using these tools as an API is not stable. What if the OS had changed
 this?
 >
 > I know, more than any of us, just how unstable these utilities are. I've
 spent months making them work on Debian, Ubuntu, Gentoo, OSX, FreeBSD,
 OpenBSD, and others, some of them with some damn strange quirks. For
 instance on OpenBSD the ps variant shows a process' uptime in...
 > - in local time
 > - with AM/PM rather than 24 hour time
 > - the whole f*ing format changes based on if the uptime is over a day or
 not
 >
 > ... in the end I decided that one was simply unparseable. I agree that
 ps, netstat, and other system commands are, in git terminology, porcelain.
 Proc contents tend to be more stable but don't exist in the BSD family. If
 I could get the data I need from tor then great. My use of system commands
 are simply because they both work well enough in practice and don't
 require developing in C (something I find about as appealing as an
 unanesthetized root canal).
 >

 That sounds painful! So I'm on the same page with that - can you confirm
 that the _one_ thing you are now missing is the state of the connections
 as the system would see them? If we can export that from tor, would that
 improve your (arm development) life overall? :)

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


More information about the tor-bugs mailing list