[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 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. 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".

 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!

 As an experiment, instead of splitting we add something: Let Tor come with
 it's own (deprivileged) application firewall/snort/IDS "protection
 daemon". It would check all incoming packets for irregularities and drop
 them. The only problem: To be of any use the daemon mustn't have access to
 the plain text, but you can only do so much filtering on encrypted
 traffic...

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