[tor-bugs] #6937 [Tor Client]: SocksPipe or SocksSocket - an anonymous pipe to smoke network leakings bug out (of)

[Tor Bug Tracker & Wiki]

#6937: SocksPipe or SocksSocket - an anonymous pipe to smoke network leakings bug
out (of)
-------------------------------------+--------------------------------------
 Reporter:  ioerror                  |          Owner:                    
     Type:  enhancement              |         Status:  new               
 Priority:  normal                   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Client               |        Version:  Tor: unspecified  
 Keywords:  security needs-proposal  |         Parent:                    
   Points:                           |   Actualpoints:                    
-------------------------------------+--------------------------------------

Comment(by ioerror):

 Replying to [comment:19 rransom]:
 > I should also add here that adding a crapload of unnecessary complexity
 to everything other than AppArmor in order to make AppArmor look less
 ineffective as a ‘security’ feature is utterly stupid.  If AppArmor can't
 block access to some AF_LOCAL sockets without blocking access to all of
 them, then AppArmor needs to be fixed.
 >

 Adding a SocksSocket to Tor isn't a crapload of unnecessary complexity. We
 already have the code for most of it in the implementation of
 ControlSocket. Furthermore, we already have some code for the client side
 ControlSocket in Vidalia.

 > And then we'll finally be assured that TBB-Firefox on Linux can't do
 anything worse than send a log of my keystrokes out over Tor and run and
 control arbitrary GUI ‘apps’ on my X display.  How comforting --
 '''NOT'''.

 On Windows we'll solve a lot of problems. We'll finally be rid of the
 local firewall problem for one. We'll also be able to isolate bundled apps
 from programs that use a SOCKS port without opening many socks ports or
 (confusing to the user) adding usernames/passwords, and so on.
 Additionally, we'll be able to write more confining jails for each
 platform for our bundled applications like Tor Browser.

 On GNU/Linux and other similar platforms, we'll similarly resolve the
 local firewall problem - which should allow us to jail users from sending
 *any* network traffic in many ways and without having to enable a
 TransPort. We'll also be able to solve our bundled app issues as well.

 Replying to [comment:19 rransom]:
 > I should also add here that adding a crapload of unnecessary complexity
 to everything other than AppArmor in order to make AppArmor look less
 ineffective as a ‘security’ feature is utterly stupid.  If AppArmor can't
 block access to some AF_LOCAL sockets without blocking access to all of
 them, then AppArmor needs to be fixed.
 >

 Adding a SocksSocket to Tor isn't a crapload of unnecessary complexity. We
 already have the code for most of it in the implementation of
 ControlSocket. Furthermore, we already have some code for the client side
 ControlSocket in Vidalia.

 > And then we'll finally be assured that TBB-Firefox on Linux can't do
 anything worse than send a log of my keystrokes out over Tor and run and
 control arbitrary GUI ‘apps’ on my X display.  How comforting --
 '''NOT'''.

 On Windows we'll solve a lot of problems. We'll finally be rid of the
 local firewall problem for one. We'll also be able to isolate bundled apps
 from programs that use a SOCKS port without opening many socks ports or
 (confusing to the user) adding usernames/passwords, and so on.
 Additionally, we'll be able to write more confining jails for each
 platform for our bundled applications like Tor Browser.

 This SocksSocket idea won't do anything to solve the fundamental X windows
 problems and that is fine. That isn't a problem that we're trying to solve
 and it seems like a red herring.

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