[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #5220 [Tor Client]: Intelligently use capabilities/privileges and drop what we don't need for Debian Gnu/Linux

#5220: Intelligently use capabilities/privileges and drop what we don't need for
Debian Gnu/Linux
-------------------------+--------------------------------------------------
 Reporter:  ioerror      |          Owner:                   
     Type:  enhancement  |         Status:  needs_information
 Priority:  major        |      Milestone:  Tor: unspecified 
Component:  Tor Client   |        Version:  Tor: unspecified 
 Keywords:  security     |         Parent:  #5219            
   Points:               |   Actualpoints:                   
-------------------------+--------------------------------------------------

Comment(by rransom):

 Replying to [comment:3 cypherpunks]:
 > > How do you propose to improve Tor's security by splitting its
 components across multiple processes/security contexts?
 >
 > High level goals would be:
 > Split network facing code from the rest and make it deprivileged. It
 would only have access to encrypted traffic coming in and out, no access
 to any keys, no access to the file system. Split relay, client, hidden
 service specific functions so they can not read each others keys, files,
 states, memory.

 Please explain in more detail so that someone can break this part.

 > Same with pluggable transport: It only accepts encrypted traffic and
 relays that to Tor. It doesn't need access to anything we care about, thus
 it mustn't be part of the TCB. This already is a "security reason".

 A pluggable transport server has access to clients' IP addresses, can log
 the times, sizes, and directions of traffic burts, and can redirect all
 connections from new clients to an attacker-controlled relay for circuit-
 level traffic logging.

 > Admittedly this is tricky because most code in Tor has to processes data
 coming in through the network and hardly anything doesn't have to have
 access to plain text communications or critical encryption keys. If the
 parts that can be deprivileged are too small you might even end up with a
 bigger TCB than before!

 Yes.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5220#comment:5>
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