[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3313 [Tor Client]: Security enhancement against malware for Tor
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs